Thread: BUG #14217: Respect $CFLAGS from /usr/local/etc/config.site
VGhlIGZvbGxvd2luZyBidWcgaGFzIGJlZW4gbG9nZ2VkIG9uIHRoZSB3ZWJz aXRlOgoKQnVnIHJlZmVyZW5jZTogICAgICAxNDIxNwpMb2dnZWQgYnk6ICAg ICAgICAgIERpbGlhbiBQYWxhdXpvdgpFbWFpbCBhZGRyZXNzOiAgICAgIGRw YS1wb3N0Z3Jlc0BhZWdlZS5vcmcKUG9zdGdyZVNRTCB2ZXJzaW9uOiA5LjZi ZXRhMgpPcGVyYXRpbmcgc3lzdGVtOiAgIExpbnV4CkRlc2NyaXB0aW9uOiAg ICAgICAgCgpjb25maWd1cmUgZ2VuZXJhdGVkIGJ5IEF1dG9jb25mIGxvYWRz IHRoZSBmaWxlICRwcmVmaXgvZXRjL2NvbmZpZy5zaXRlIGFuZAppZiBDRkxB R1MgaXMgZGVmaW5lZCB0aGVyZSwgaXRzIHZhbHVlIGlzIHVzZWQgd2hlbiBi dWlsZGluZyB0aGUgcHJvamVjdC4NCg0KQmVjYXVzZSBpbiBwb3N0Z3Jlc3Fs IGNvbmZpZ3VyZS5pbiBjb250YWlucyBvbiBsaW5lIDQwMCAidW5zZXQgQ0ZM QUdTIiB0aGUKdmFsdWUgb2YgJENGTEFHUyBmcm9tIGNvbmZpZy5zaXRlIGlz IGRpc2NhcmRlZCB3aGVuIGJ1aWxkaW5nIHBvc3RncmVzcWwsCmNvbnRyYXJ5 IHRvICRMREZMQUdTIGZyb20gY29uZmlnLnNpdGUuDQoNClBsZWFzZSByZW1v dmUgdGhlICJ1bnNldCBDRkxBR1MiIGZyb20gY29uZmlndXJlLmluIGFuZCBj b25zaWRlciByZXBsYWNpbmcKQ0ZMQUdTPSItdiIgaW4gc3JjL3RlbXBsYXRl cy9saW51eCB3aXRoIENGTEFHUz0iJENGTEFHUyAtdiIuCgo=
dpa-postgres@aegee.org wrote:
> The following bug has been logged on the website:
>
> Bug reference: 14217
> Logged by: Dilian Palauzov
> Email address: dpa-postgres@aegee.org
> PostgreSQL version: 9.6beta2
> Operating system: Linux
> Description:
>
> 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.
This report is correct; we're not doing the right thing here. The
autoconf manual explicitely says:
Site files are also good places to set default values for other output
variables, such as CFLAGS, if you need to give them non-default values:
anything you would normally do, repetitively, on the command line. If
you use non-default values for prefix or exec_prefix (wherever you
locate the site file), you can set them in the site file if you specify
it with the CONFIG_SITE environment variable.
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Site-Defaults.html
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. The line was added by this commit:
commit 801427abc2924195b35be19abe4f64dbbea82263
Author: Peter Eisentraut <peter_e@gmx.net>
AuthorDate: Sat Nov 1 20:48:51 2003 +0000
CommitDate: Sat Nov 1 20:48:51 2003 +0000
Unset CFLAGS before reading template. This should be more robust.
When --enable-debug is used, then the default CFLAGS for non-GCC is just
-g without -O.
Backpatch enhancement of Autoconf inline test that detects problems with
the HP C compiler.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> dpa-postgres@aegee.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
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 buildsystem, 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 haveCFLAGS in the enviroment, in config.site nor have it passed on the command line, and compiling with GCC, -g is put intoCFLAGS. 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 useboth CFLAGS and PG_CFLAGS. This is the approach of Automake: whenever it changes the compiler flags, it amends to AM_CFLAGSand 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, isknown. 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@2ndquadrant.com> writes: >> dpa-postgres@aegee.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 >
On 6/28/16 5:04 PM, ÐилÑн ÐалаÑзов wrote: > When building postgresql I noticed, that it doesn't use LTO. What is the way to enable LTO builds with the current buildsystem, except calling CFLAGS="-flto -O3" ./configure? You can do it like that. But I have tried that before and the performance improvement of the resulting binary is approximately zero percent. So there is not a whole lot of enthusiasm right now to make that any easier. > In all cases, doing unset CFLAGS is wrong, as it discards CFLAGS set in config.site, which it shall not. As a workaround, you can fake it by setting ac_env_CFLAGS_set and ac_env_CFLAGS_value in config.site, to pretend that CFLAGS came from the environment. We do support that. If you want to come up with a more comprehensive patch to make this work right, we would consider it. But as you've heard, this is a very marginal use case and the current system has been carefully tweaked, so it would take some convincing to change it. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services