> From: Bruno Haible <[email protected]> > 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.
