On Thu, Feb 12, 2026 at 09:48:56PM +0100, Bruno Haible wrote: > Hi Gavin, > > Back to the "texinfo-7.2.90 on Solaris 10" thread: > > > I am not surprised (this is for makeinfo/texi2any only, not for the Info > > > reader). For Perl C and to have consistent link and compile flags, we > > > now use the Perl flags for all the libraries and executables. Therefore > > > it has become difficult to modify the flags or the compiler. Note, > > > however, that using a different compiler (and different flags) than the > > > one used to build Perl was not supposed to work since a long time, > > > according to Perl documentation, although it worked in practice on some > > > platforms. > > > > I suppose it would still be possible to try building with different compiler > > flags if the user checks which Makefile variables are being used, and > > overrides > > them from the command line. For example, they can run > > make 'perl_conf_LIB_LDFLAGS=...' and so on. So it is not completely > > impossible > > to try to build with a different C compiler than that specified by "perl > > -V", > > just requires a lot of investigation into Makefile internals. > > > > I don't see a need at present to try to make this easier (e.g. by > > documenting perl_conf_LIB_LDFLAGS etc. as user-modifiable, alike to CC, > > CFLAGS etc.). > > I think using Perl's C compiler and options instead of arbitrary different > ones > is a good measure in order to avoid "unexplainable" malfunction. > > However, the need I see is when Perl's C compiler is not available (for > example, > if it was a proprietary compiler in the first place). In this case, now, > texinfo > cannot be built at all, without rebuilding Perl too.
It should be possible to build it with XS modules disabled. > The concept that should make this reasonably manageable is the ABI. For > instance, > on Linux/x86_64, there are 3 ABIs: the x86_64 ABI, the x86 ABI, and the x32 > ABI. > The principle is that code compiled by different compilers but that obeys the > same ABI is compatible. > > So, IMO the way to go forward with this, i.e. to allow a different compiler > but without running into link errors, is > 1) from the Perl configuration, extract the ABI, > 2) from $CC and $CFLAGS, extract the ABI (e.g. using Gnulib's > gl_HOST_CPU_C_ABI > macro, module 'host-cpu-c-abi'), > 3) compare the two ABIs and err out if they are different. > > Bruno > > > Unfortunately builds tend to break in strange ways if the compiler flags aren't exactly the same way, even if the ABI as you describe matches. For example, there was this issue: https://lists.gnu.org/archive/html/bug-texinfo/2025-11/msg00023.html I don't have a complete understanding of all the different ways it can fail, but here it appeared to be with inconsistent use of -I flags and/or flags to specify libraries to link against. If files are built against different include files (in this case it was for a "gettext" function), then they may get incompatible definitions. -D flags can cause header files to behave differently, and so on. We've gone through multiple changes in how XS modules are built over the years, in an attempt to make it reliable and correct. Here are some of Perl's flags, listed in the copy of tta/config.log in my build tree: perl_conf_CFLAGS='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' perl_conf_CPPFLAGS='-I/usr/lib/x86_64-linux-gnu/perl/5.38/CORE' perl_conf_EMBED_LIB_CFLAGS='-fPIC' perl_conf_LDFLAGS='-Wl,-E -fstack-protector-strong -L/usr/local/lib' perl_conf_LIBS='-L/usr/lib/x86_64-linux-gnu/perl/5.38/CORE -lperl' perl_conf_LIB_CFLAGS='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC' perl_conf_LIB_LDFLAGS='-Wl,-E -fstack-protector-strong -L/usr/local/lib' I can't say I know what every single one of those flags does, but I am sure that most of them would be needed for correct compilation, so that extension code is binary compatible with the Perl interpreter. I don't think it would be right to junk them all and compile the extension code with a completely different compiler with a different set of flags.
