On Sun, Nov 16, 2025 at 12:48:07PM +0100, Patrice Dumas wrote:
> > Weren't there other failures on AlmaLinux that this flag was added for?
>
> Yes, there were. In the ChangeLog I wrote 'Could be needed on
> AlmaLinux'. But it is not actually could, it is needed. I remember
> that I found the information in a bug report or in a forum post. The
> flags in PERL_EXTUTILS_EMBED_ldopts have some flags in them that require
> corresponding "source fortification" flags in CFLAGS, otherwise there
> is an error of result not being relocatable.
>
> > Maybe there are other ways to fix the problem on AlmaLinux other than
> > adding this flag.
>
> Probably not so easy to determine, I couldn't reproduce the issue on
> cfarm.
As we don't understand the issue very well or the justification for
adding the flags, and they are not needed or harmful on platforms we
can test better, we shouldn't add them.
Could it help to use a subset of PERL_EXTUTILS_EMBED_ccopts instead for
ctexi2any_CPPFLAGS?
>From the ExtUtils::Embed man page:
ccflags(), ccdlflags()
These functions simply print $Config{ccflags} and $Config{ccdlflags}
ccopts()
This function combines perl_inc(), ccflags() and ccdlflags() into one.
(It looks wrong to use ccopts in CPPFLAGS as this variable is only
for preprocessor flags like -I and -D.)
Broadly speaking: I don't have a good understanding of all of this.
It's quite easy to understand the idea that the same compiler and compiler
flags should be used for configure checks and for running the compiler
and linker - otherwise, the tests may produce a configuration that
doesn't work.
What we seem to have is a collection of source files that have to be
built under varying conditions that don't always match those of configure
checks.
So it doesn't make sense to me, for example, that we would use the
value of CC from the perl configuration throughout tta/configure.ac
(and for building in tta/C/Makefile.am), but not the value of CFLAGS
from the perl configuration.
Then some of the libraries are linked together with _LIBADD
variables, even though they've potentially been compiled differently
and may not necesessarily be compatible.
There is a "platform_PERL_LIBADD" variable used throughout tta/C/Makefile.am
which does not appear to be set anywhere, as far as I can tell.
It was simpler when the XS code was more limited and we made much less
use of gnulib. In that case all of the C code in the XS subdirectory
was compiled with the compiler and flags for XS extensions.
As I remember, gnulib definitions and Perl definitions (from Perl
header files) would sometimes clash, leading you to go to the effort
of separating the two.
> We probably have to decide ourselves if we want to prefer
> * consistency between CFLAGS and LDFLAGS
> * avoiding mixing Perl headers and gnulib/autoconf generated config.h
> and code
