On Sun, Nov 16, 2025 at 04:55:45PM +0000, Gavin Smith wrote:
> 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.
I agree. We could do something adhoc in the CI such as a sed
substitution for Alma Linux if nothing else works.
> Could it help to use a subset of PERL_EXTUTILS_EMBED_ccopts instead for
> ctexi2any_CPPFLAGS?
Possibly, or for CFLAGS only. I wanted to use ExtUtils::Embed as is to
follow the documentations on embedding Perl, but we can also do
something cleaner by ourselves. My feeling is that it should work, I'll
have a try.
> 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.
Note that the ExtUtils::Embed man page is inaccurate, ccopts only combines
ccflags and perl_inc.
> (It looks wrong to use ccopts in CPPFLAGS as this variable is only
> for preprocessor flags like -I and -D.)
Agreed.
(Same for ExtUtils::Embed -ldopts, which combines LDFLAGS and LIBS).
> Broadly speaking: I don't have a good understanding of all of this.
You have some, as you actually reimplemented what ExtUtils::Embed does, with
more granularity with tta/m4/txi_perl_conf.m4. And you can do relevant
proposals...
> 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.
No, there are two settings, each with a specific way to do configure
checks. Maybe it is not well explained, but it is relatively simple.
There are only two "perl C" configure checks, one in tta/m4/txi_libperl_link.m4
and the other in tta/m4/txi_embedded_perl.m4, all the other checks are
"pure C" autoconf and gnulib typical checks.
Then the _CPPFLAGS, _LIBADD, _LDFLAGS and _CFLAGS need to be carefully
specified for the diverse libraries, depending on whether they contain
"perl C" or "pure C" code, this part is not particularly complex, there
are two cases, and two different sets of flags but maybe more prone to
errors. What is more a pain is that the libraries interdependencies
need to be correct, and the LIBINTL and similar need to be specified
correctly.
> 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.
That makes perfect sense to me, we compile "pure C" code against
gnulib/autoconf config.h and headers => no need for Perl CFLAGS in that
case. We compile "perl C" code against Perl headers => we need the Perl
CFLAGS in that case.
> 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.
Not compatible in which sense? In term of binary interfaces?
In the code, we need to be careful to use separate functions for memory
management, but it is something that is quite well documented in the
code, and although it is a bother, it is not such an issue. And it is
not something new, this is probably an issue since the first
implementation of XS for the parser.
> 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 is set in tta/m4/txi_perl_conf.m4, on platforms that need to be
linked with no-undefined, it adds that link flags to link against
libperl. And it is mainly derived from the code you did...
> 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.
It was not so simple, there were kludges since a long time that, in my
opinion, were as bad as the current state of separation of code, to
undefine symbols. Currently the separation is a bit of a pain because
it adds constraints on which function should go to which file, but
overall it seems much cleaner to me. And I also remember that a
platform that failed in a strange way was fixed as a side-effect of
separating "pure C" with gnulib and "perl C" for compilation.
> 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.
--
Pat
