On Sat, Nov 15, 2025 at 07:17:49PM +0000, Gavin Smith wrote: > On Thu, Nov 13, 2025 at 07:25:13PM +0000, Gavin Smith wrote: > > > You can see that the -I/opt/csw/include option is given on the first > > run of "cc". On this system, this directory contains a GNU "libintl.h" > > file which appears to redefine "gettext" as "libintl_gettext". This flag > > appears to come from the Perl configuration values: > > > > perl_conf_CFLAGS='-D_REENTRANT -xO3 -m32 -xarch=pentium_pro > > -xchip=pentium_pro -I/opt/csw/bdb48/include -I/opt/csw/include > > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV -KPIC'
That is a good thing you found out why some opencsw build faild, I had found out that there was something wrong with libintl, but couldn't understand what had changed. > > But this is not used for the tests in tta/configure.ac. Code to use this > > value in the value of CFLAGS is commented out: > > > > # The usual configure checks use the Autoconf/Gnulib includes, but do not > > > > # compile nor link against Perl. The result of those checks are used for > > > > # code never compiled with the Perl flags. Therefore we do not set the > > Perl > > # more specific flags, but use the user-defined. > > > > CFLAGS=$PERL_EXT_CFLAGS > > > > CPPFLAGS=$PERL_EXT_CPPFLAGS > > > > LDFLAGS=$PERL_EXT_LDFLAGS > > > > # Specific checks against Perl should not have the Autoconf/Gnulib > > includes > > # but could set the following: > > > > #CFLAGS="$PERL_EXT_CFLAGS $perl_conf_CFLAGS" > > > > #LDFLAGS="$PERL_EXT_LDFLAGS $perl_conf_LDFLAGS" > > > > This was changed on 2025-01-31 (commit b1ecc743d), and further changed on > > 2025-07-14 (commit 1c8d0009d64). > > > > I see that you (Patrice) edited the comments around this code today. > > I found by testing on the Solaris 11 system that the $perl_conf_CFLAGS were > needed in CFLAGS, and the build would succeed with this. > > I was going to commit a change to use these flags, but it conflicts with > your change. I think that adding those flags is probably wrong to find libintl. Indeed, the code that is compiled against libintl headers should not be compiled against Perl headers. libintl headers should be found through gettext/gnulib/autoconf macros, not through Perl. I do not know what should be done exactly to have it work on those opencsw builds, but it should probably be something different. > Would using these flags break anything on any platforms? Possibly, but I am not sure about that. It is indeed possible that an include file that is used by gnulib/autoconf could be found in the Perl flags include directories and be wrong, but that is only a speculation. However, even if it idid not break anything, it still seems wrong to me to use the Perl flags to find includes solely needed by "pure C" code not compiled against Perl and using the autoconf/gettext/gnulib macros to find linintl and other similar libraries. > In the past, all the code under tp/Texinfo/XS was built with the Perl flags, > as far as I remember. > > Following the code reorganisation in February 2025, which you referred to > in this message: This is not really the change that made the flags separate. I separated the flags to have files compiled against Perl headers distinct from files compiled against gnulib headers and autoconf-generated config.h, because they are incompatible on some platforms, in particular mingw/cygwin. This was done for 7.2. See for example 2024-11-14 Patrice Dumas <[email protected]> add libxsutils and libxs_in_libtexinfo convenience libraries to be able to use different CPPFLAGS for compiltation. libxsutils contains only xs_utils and does not require any CPPFLAGS. This allows to avoid including config.h directly or indirectly in call_perl_function.c and api_to_perl.c and be fully independent of gnulib and autoconf. > https://lists.gnu.org/archive/html/bug-texinfo/2025-02/msg00002.html > > Perhaps the organisation of the code needs to be tweaked to separate XS and > non-XS C code more, so they don't share the same configure checks? This is not really possible, as far as I can tell, because there are libraries that need to contain both code compiled against Perl headers and code compiled against autoconf/gnulib config.h. This is achieved by using a convenience library for the code compiled against Perl headers to be able to use different compile flags. For example, in tta/C/Makefile.am, the libtexinfo code in libtexinfo_la_SOURCES corresponds only to code compiled against autoconf/gnulib config.h not using the Perl flags, and there is a convenience library, libcallperl_libtexinfo.la for codes that are built using Perl flags. Then libcallperl_libtexinfo.la is in libtexinfo_la_LIBADD. > Here's what you wrote in a private mail on 2025-01-19, explaining how > the code would be reorganised: > > I had another quite different idea, which would be to have a toplevel > texi2any (or t2a for brievity), that would contain a configure.ac, which > would be more or less the current Texinfo/XS configure.ac, tests and > some common data, and would contain a perl directory for texi2any.pl, > the Texinfo modules and the XS interfaces in the XS directory, and a > C directory that would contain texi2any.c and all the lib and code > currently in Texinfo/XS except for the .xs that would be in the perl > subdirectory. The code would be build in the C directory first to build > all the libraries and in the perl directory afterwards. The only > inter-directories dependency would be the .la needed by the perl XS > modules. What I do not tell clearly in that part is that in the C directory there are files compiled against Perl, even though there are no XS interfaces. The files compiled against Perl are diverse, some could probably be split out and be moved to the XS directories, but not all, code in files like tta/C/main/api_to_perl.c and tta/C/main/call_perl_function.c need to be mixed with "pure C" code. -- Pat
