On Sat, Jan 11, 2025 at 04:11:26PM +0100, Patrice Dumas wrote:
> Hello,
>
> The ExtUtils::Embed ccopts and ldopts are a kind of reference for
> compile and link flags that should work when linking against Perl.
> Based on the flags used/output by ExtUtils::Embed, I have some proposals
> on changes for the flags we use for XS modules.
>
> 1) (Minor) I propose to add -I$(PERL_INC) directly in perl_conf_CFLAGS instead
> of adding it in tp/Texinfo/XS/Makefile.am
The autoconf manual says that -I options belong in CPPFLAGS:
-- Variable: CPPFLAGS
Preprocessor options for the C, C++, Objective C, and Objective C++
preprocessors and compilers. If it is not set in the environment
when ‘configure’ runs, the default value is empty. ‘configure’
uses this variable when preprocessing or compiling programs to test
for C, C++, Objective C, and Objective C++ features.
This variable's contents should contain options like ‘-I’, ‘-D’,
and ‘-U’ that affect only the behavior of the preprocessor. Please
see the explanation of ‘CFLAGS’ for what you can do if an option
affects other phases of the compiler as well.
Maybe -I$(PERL_INC) could be added to CPPFLAGS in configure.ac?
> 2) I propose to drop $PERL_CONF_optimize from perl_conf_CFLAGS since it
> is not set in ExtUtils::Embed ccopts. It would avoid the frequent
> inconsistencies between PERL_EXT_CFLAGS and PERL_CONF_optimize. It
> could lead to binary incompatibilities, but I doubt it since it is
> not in ExtUtils::Embed ccopts.
I see, is this becuase we do
CFLAGS="$PERL_EXT_CFLAGS $perl_conf_CFLAGS"
and perl_conf_CFLAGS has PERL_CONF_optimize in it, so if the user
set PERL_EXT_CFLAGS to e.g. -O2 and PERL_CONF_optimize had -O3, both
optimization options would go in the variable? That makes sense.
> 3) I propose to use ldflags in perl_conf_LDFLAGS. It is described as
> This variable contains any additional C loader flags desired by the user. It
> is up to the Makefile to use this.
> Note that on Debian testing it leads to the addition of
> -fstack-protector-strong
> which could lead to spurious warning if combined with -O0 in
> PERL_EXT_CFLAGS, but I still think that it is better to add it.
It appears that ExtUtils::MakeMaker (Perl build system for XS modules,
which we don't use, but which the current build system was kind of
bootstrapped from) also refers to ldflags although I don't know exactly
how it uses it.
We did in fact discuss this flag in the past:
On 1 January 2016 at 11:08, Eli Zaretskii <address@hidden> wrote:
> The next problem was with linking TestXS as a shared library. Because
> no undefined references are allowed when linking a shared library on
> MS-Windows, the linker needs to see an import library which tells it
> where to find the Perl functions at run time. This library is found
> like this:
>
> perl -V:libperl
>
> The result is a file name, like libperl520.a, with no leading
> directories, so one needs also the suitable linker flags before that,
> which can be obtained with
>
> perl -V:ldflags
>
> The result (after converting it in fetch_conf) should be added to the
> value of PERL_CONF_cccdlflags.
https://lists.gnu.org/archive/html/bug-texinfo/2016-01/msg00009.html
I don't remember why I objected to using "ldflags" at the time.
Generally, perl Config values might not necessarily match up perfectly
with the variables in an automake build system so I would not be concerned
about using every variable, but it might make sense to be consistent
with the flags output from ExtUtils::Embed if those are the ones used
when embedding Perl.
> 4) I suggest adding perllibs to PERL_LIBS, which is only used on
> platforms needing -no-undefined. It could be possible that it causes
> the link to fail as some libraries libperl is linked against are
> missing, but since it is in ExtUtils::Embed ldopts, it should be ok
> and maybe even needed for some platforms we have not encountered yet.
> It is described as
> The list of libraries needed by Perl only (any libraries needed by
> extensions only will by dropped, if using dynamic loading).
You could try adding it.
> lddflags could also have been a good candidate (not in ExtUtils::Embed
> flags because the ExtUtils::Embed target linking programs, not
> libraries), but chances are that it duplicates the libtool flags. Also,
> it is UNKNOWN on a Debian testing, so I think that we should not use
> that Config variable.
"lddflags" is not documented in "man Config" so I don't know if it is
a real variable.
