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

Поиск
Список
Период
Сортировка
От Дилян Палаузов
Тема Re: BUG #14217: Respect $CFLAGS from /usr/local/etc/config.site
Дата
Msg-id 6d7e8113-ee42-6f45-2c90-ca9bf831ee7e@aegee.org
обсуждение исходный текст
Ответ на Re: BUG #14217: Respect $CFLAGS from /usr/local/etc/config.site  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #14217: Respect $CFLAGS from /usr/local/etc/config.site  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-bugs
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
>



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: BUG #14016: Incomplete documentation of IN subquery expression
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: BUG #14150: Attempted to delete invisible tuple