On Mon, Jan 13, 2025 at 07:41:32PM +0000, Gavin Smith wrote: > 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:
Ok. > -- 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? I prefer setting perl_conf_CPPFLAGS. Note that ExtUtils::Embed mixes CFLAGS and CPPFLAGS, and also mixes LDFLAGS and LIBS, but when we do it ourselfs, I agree that we should be as correct as possible. > > 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. > > We did in fact discuss this flag in the past: > > 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. I reread the theread and you did not really object, you just didn't add it, if I understood well. > 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. And if they are problematic we could still change again if there are issues for some platforms. > > 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. I mistyped, it is lddlflags. On my platform it is lddlflags='-shared -L/usr/local/lib -fstack-protector-strong'; so, it is -shared $ldflags I think that this is not needed, I guess/hope that libtool already does the right thing better. -- Pat
