Compilation Failure in Master

[Jean-Marc Lasgouttes]

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?

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