Re: BUG #14217: Respect $CFLAGS from /usr/local/etc/config.site

Hello,

if no CFLAGS are specified, autoconf's configure uses "-O2 -g" by default. This is what is meant in the cited text at https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Site-Defaults.html .

In my config.site I have
GCC=yes
CFLAGS="-pipe -O3 -fno-fat-lto-objects -flto" CXXFLAGS="-pipe -O3 -fno-fat-lto-objects -flto" LDFLAGS="-Wl,-O1,-s -flto=8"
enable_static=no enable_shared=yes
enable_silent_rules=yes

When building postgresql I noticed, that it doesn't use LTO. What is the way to enable LTO builds with the current build system, except calling CFLAGS="-flto -O3" ./configure?

In my opinion, ./configure shall not deal explicitly with --enable-debug, as ./configure inserts by default -g to CFLAGS, if the latter is unset and the compiler supports it. In all other projects, when you just do ./configure, don't have CFLAGS in the enviroment, in config.site nor have it passed on the command line, and compiling with GCC, -g is put into CFLAGS. With other words, when I compile other project when and don't want debug symbols, I have to be explicit.

The assumption is that the one who touches config.site best knows how to compile software on the system: in this case with -flto, and the variables from there have precedence over the templates.

An option is to put all settings determined during configure time in another variable PG_CFLAGS, and when compiling to use both CFLAGS and PG_CFLAGS. This is the approach of Automake: whenever it changes the compiler flags, it amends to AM_CFLAGS and when compiling, AM_CFLAGS and CFLAGS are both passed to the compiler.

In all cases, doing unset CFLAGS is wrong, as it discards CFLAGS set in config.site, which it shall not.

That the cache file breaks, if the configuration process is not reproducible as a build is tried with different CFLAGS, is known. Maybe this is intended. Let's assume autoconf know what do to, when CFLAGS is provided on the command line with ./configure, on the command line with make, in the environment and in config.site.

Greetings
Dilian

On 06/28/2016 06:05 PM, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> dpa-postgres(at)aegee(dot)org wrote:
>>> configure generated by Autoconf loads the file $prefix/etc/config.site and
>>> if CFLAGS is defined there, its value is used when building the project.
>>> Because in postgresql configure.in contains on line 400 "unset CFLAGS" the
>>> value of $CFLAGS from config.site is discarded when building postgresql,
>>> contrary to $LDFLAGS from config.site.
>
>> The way it works today completely ignores settings in config.site, which is
>> clearly bogus per the above manual, but I doubt that blanket removal of the
>> "unset" is the right solution.
>
> I think the thing we'd have to work out is what's the proper interaction
> between the template files and the config.site file. It's worth noting
> that most of the cases where template files set CFLAGS are when we've
> detected a non-default compiler. In such cases, it's not exactly clear
> to me that honoring CFLAGS from config.site would be helpful, as such a
> setting probably is meant for the default compiler.
>
> Another point here is that any setting coming from config.site is
> presumably not going to vary in response to --enable-debug, which
> could be problematic, especially so for non-gcc compilers.
>
> Also, it looks to me like the autoconf script will fail outright if
> config.site specifies CFLAGS and the user has tried to specify a
> different CFLAGS in the environment or command line --- see the
> logic that checks for cache file corruption.
>
> In short, I'm pretty dubious about the utility of this feature, which
> may explain why nobody has complained about our current behavior
> for over a dozen years. Still, it *is* inconsistent that we are
> only discarding CFLAGS and not other variables that might come from
> such a file.
>
> regards, tom lane
>