On Thu, May 15, 2025 at 04:48:55PM +0200, Jean-Marc Lasgouttes wrote: > 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?
Do you mean CMake should turn set LYX_EXTERNAL_ICONV passed on the version of the compiler? I still don't know why it succeeds for me (with the default of LYX_EXTERNAL_ICONV=OFF) and not for Riki. Could be different compiler versions or could be different othe CMake flags. Kornel does it compile successfully (although with warnings) for you? > At this time, upgrading libiconv seems a lot of work for a dubious return. +1 > 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?). Scott
signature.asc
Description: PGP signature
-- lyx-devel mailing list lyx-devel@lists.lyx.org https://lists.lyx.org/mailman/listinfo/lyx-devel
