Re: CC and CFLAGS are ignored by part of the build
On Tue, Nov 14, 2023 at 08:40:54AM +0100, Patrice Dumas wrote: > The other is that PERL_CONF_optimize is used for AM_CFLAGS > (XSLIBS_CFLAGS in the development version), the objective being that the > same flags as those used to build perl are used for perl XS modules. I > guess that these flags could be overriden by setting another flag, but > will still be on the command line. I checked that the flags are overridden. $(CFLAGS) appears on the command line after $(AM_CFLAGS) (or the equivalent target-specific variable). Optimisation flags given in PERL_EXT_CFLAGS will override any in e.g. XSParagraph_la_CFLAGS. (See Info node (automake)Flag Variables Ordering.) When running "make", it is CFLAGS instead, which was set from PERL_EXT_CFLAGS in configure, so you can do 'make XSParagraph_la-XSParagraph.lo CFLAGS=-g'. (The GNU Coding Standards say that overriding CFLAGS when running make should be possible.)
Re: CC and CFLAGS are ignored by part of the build
On Tue, Nov 14, 2023 at 02:22:00PM +0200, Eli Zaretskii wrote: > AFAIU, that's impossible in general, because CFLAGS could include > flags that cannot be applied to both CC and PERL_CONF_cc due to > compatibility issues, since Perl could have been built using a very > different compiler. > > IMNSHO, it isn't a catastrophe that compiling Perl extensions needs a > separate C flags variable. It is basically similar to CFLAGS and > CXXFLAGS being separate for building the same project (which happens > inj practice, for example, in GDB, which is part C and part C++). And > if the GCS doesn't cater for these (relatively rare and specialized) > situations, then I think the GCS needs to be amended. There's no need > to be dogmatic about this. > These variables were mentioned in the output of ./configure --help but we never documented anywhere why they were needed, as far as I could tell. I've added text to the INSTALL file: + When `configure' is running in the XS subdirectory, instead of the + standard CC, CFLAGS, LDFLAGS etc., it uses special variables with a + PERL_EXT_ prefix. These are all listed in the output of `configure + --help'. This is necessary because it is possible that the C compiler + being used to compile Perl extension modules is a different compiler + to that used for the rest of the package. (However, if you need to + override these variables when running `make', use the unprefixed + variants, e.g. CFLAGS instead of PERL_EXT_CFLAGS. Exception: you + cannot override CPPFLAGS this way as gnulib uses this variable.)
Re: CC and CFLAGS are ignored by part of the build
> From: Bruno Haible > Date: Tue, 14 Nov 2023 04:23:58 +0100 > > Apparently some optimization options were still in effect. And indeed, > the file tp/Texinfo/XS/config.status contains these lines: > > CC='sparc64-linux-gnu-gcc' > compiler='sparc64-linux-gnu-gcc' > LTCC='sparc64-linux-gnu-gcc' > compiler='sparc64-linux-gnu-gcc' > S["CPP"]="sparc64-linux-gnu-gcc -E" > S["ac_ct_CC"]="sparc64-linux-gnu-gcc" > S["CC"]="sparc64-linux-gnu-gcc" > S["PERL_CONF_cc"]="sparc64-linux-gnu-gcc" > S["PERL_CONF_optimize"]="-O2 -g" > > Per the GNU Coding Standards [1], when I specify CC and CFLAGS, it should > override the package's defaults. > > I understand that perl comes with its own installation and that building > code that can be dynamically loaded by perl can be challenging. But the > CC and CFLAGS values that I have specified are ABI-compatible with > the ones that perl wants. Therefore I expect them to be obeyed. AFAIU, that's impossible in general, because CFLAGS could include flags that cannot be applied to both CC and PERL_CONF_cc due to compatibility issues, since Perl could have been built using a very different compiler. IMNSHO, it isn't a catastrophe that compiling Perl extensions needs a separate C flags variable. It is basically similar to CFLAGS and CXXFLAGS being separate for building the same project (which happens inj practice, for example, in GDB, which is part C and part C++). And if the GCS doesn't cater for these (relatively rare and specialized) situations, then I think the GCS needs to be amended. There's no need to be dogmatic about this.
Re: CC and CFLAGS are ignored by part of the build
On Tue, Nov 14, 2023 at 04:23:58AM +0100, Bruno Haible wrote: > Hi, > > Apparently some optimization options were still in effect. And indeed, > the file tp/Texinfo/XS/config.status contains these lines: > > S["PERL_CONF_optimize"]="-O2 -g" > > Per the GNU Coding Standards [1], when I specify CC and CFLAGS, it should > override the package's defaults. > > I understand that perl comes with its own installation and that building > code that can be dynamically loaded by perl can be challenging. But the > CC and CFLAGS values that I have specified are ABI-compatible with > the ones that perl wants. Therefore I expect them to be obeyed. There may be two issues here. One is that in Texinfo/XS the following variables replace the usual ones, to be able to specify something different for the info program and the perl XS modules: PERL_EXT_CFLAGS PERL_EXT_CPPFLAGS PERL_EXT_LDFLAGS PERL_EXT_CC The other is that PERL_CONF_optimize is used for AM_CFLAGS (XSLIBS_CFLAGS in the development version), the objective being that the same flags as those used to build perl are used for perl XS modules. I guess that these flags could be overriden by setting another flag, but will still be on the command line. In the development version XSLIBS_CFLAGS is only used to compile C perl (mostly), most of the 'pure C' code does not use this variable, but still use PERL_EXT_*. -- Pat
CC and CFLAGS are ignored by part of the build
Hi, I'm trying to build texinfo-7.1 on Linux/sparc64, in order to debug a problem. I configured the package with CC="gcc -fsanitize=undefined" \ CFLAGS="-O0 -fno-omit-frame-pointer -ggdb" \ gl_cv_func_obstack=yes \ ../configure --prefix=$HOME/prefix64 \ CPPFLAGS="-I$HOME/prefix64/include -Wall" \ LDFLAGS="-L$HOME/prefix64/lib" and then, in the tp/Texinfo/XS/ subdirectory, under gdb, I get stack frames like this one: #2 0xf801012ec09c in setup_document_root_and_before_node_section () at ../../../../tp/Texinfo/XS/parsetexi/parser.c:523 523 add_to_element_contents (document_root, before_node_section); (gdb) info locals before_node_section = 0x127cf54 document_root = Apparently some optimization options were still in effect. And indeed, the file tp/Texinfo/XS/config.status contains these lines: CC='sparc64-linux-gnu-gcc' compiler='sparc64-linux-gnu-gcc' LTCC='sparc64-linux-gnu-gcc' compiler='sparc64-linux-gnu-gcc' S["CPP"]="sparc64-linux-gnu-gcc -E" S["ac_ct_CC"]="sparc64-linux-gnu-gcc" S["CC"]="sparc64-linux-gnu-gcc" S["PERL_CONF_cc"]="sparc64-linux-gnu-gcc" S["PERL_CONF_optimize"]="-O2 -g" Per the GNU Coding Standards [1], when I specify CC and CFLAGS, it should override the package's defaults. I understand that perl comes with its own installation and that building code that can be dynamically loaded by perl can be challenging. But the CC and CFLAGS values that I have specified are ABI-compatible with the ones that perl wants. Therefore I expect them to be obeyed. Bruno [1] https://www.gnu.org/prep/standards/html_node/Command-Variables.html
