Le 15/05/2025 à 12:31, Scott Kostyshak a écrit :
On Thu, May 15, 2025 at 08:49:32AM +0200, Jean-Marc Lasgouttes wrote:
Le 15 mai 2025 01:46:37 GMT+02:00, Richard Kimberly Heck <rikih...@gmail.com> a
écrit :
I was just using defaults:
mkdir build
cd buildcmake ..; and that's it. If I set LYX_EXTERNAL_ICONV to ON, then it
builds. The error seems to be in building iconv itself.
We ship libinconv 1.15. It might be that the latest 1.18 is better with GCC 15.
Could be nice. Would now be a good time to do this? If there is a patch/branch
I can test compilation on both GCC and Clang and CMake and autotools.
I began to do it, but this is insane. Currently, we only have in
3rdparty/ a subset of the full libiconv tree, but I am not sure which one.
I actually do not know how the 1.15 tree has been pruned (currently
downloading the 1.15 tree to figure that out).
I note that the commit for autoconf support of libiconv states:
=====
commit 08afc52c4cc5fe8740722d7715fd66baa3dd9ffa
Author: Georg Baum <b...@lyx.org>
Date: Thu May 5 19:43:24 2016 +0200
Configure included iconv with autotools
The included iconv should not be used on Linux or OS X, but
(depending on
local configuration) it might be needed for crosscompiling a mingw
target
from Linux. Now the user can choose whether to use the included
iconv or not.
cmake does already support that.
eilseq.m4 was taken from the original libiconv 1.14 package.
======
My question is thus: Riki, do you _need_ this to work, or is it just
that cmake is proposing the wrong defaults?
At this time, upgrading libiconv seems a lot of work for a dubious return.
I'd love to see this replaced by ICU or Qt wrapper around ICU. Using
directly ICU seems dangerous, since Qt comes with its own copy (does it?).
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
https://lists.lyx.org/mailman/listinfo/lyx-devel
