Compilation Failure in Master

[Scott Kostyshak]

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 <rikiheck at 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 <baum at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20250515/6a97685a/attachment.sig>