On Wed, Nov 21, 2012 at 1:20 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
On Wed, Nov 21, 2012 at 8:02 PM, Ian Lance Taylor <iant@google.com> wrote:
The main advantage is that you can compile a program with CFLAGS="-O2 -g
-fPIE", and libtool's adding of -fPIC for shared libraries will work
reliably. If -fPIE can still override -fPIC, the result depends on
whether -fPIC comes before or after CFLAGS.
...which is exactly how all our other options work. The last one
wins. Why should these be different?
Most other options are not added by the build system automatically
with the presumption that they always override the default.
I don't think that GCC can predict what various different build
systems are going to do.
Using -fPIE in CFLAGS for
libtool seems like a very specific use case
It's actually a very common use case for distributions that want to
harden some binaries.
Well, OK. I could actually give you the reverse argument--I ran into
this working with Google's internal build system, where it was a
problem--but it doesn't really matter. My view is this: we have a
simple rule for options that is very easy to understand. We should
only deviate from that rule for exceptional reasons. The fact that
libtool acts a certain way is not an exceptional reason; libtool can
change behaviour easily enough, and that change will be backward
compatible.
Note that even before my patch, gcc -fpic -fpie was equivalent to
-fpie. What changed is that previously gcc -fpie -fpic was also
equivalent to -fpie. So if you were adding -fpie to CFLAGS, and
libtool was not aware of that, the result was that when libtool
expected -fpic it was actually getting -fpie. I don't see how that
could be correct anyhow.
Ian