On 21/11/12 22:47, Ian Lance Taylor wrote:
On Wed, Nov 21, 2012 at 1:20 PM, Paolo Bonzini <bonz...@gnu.org> wrote:
On Wed, Nov 21, 2012 at 8:02 PM, Ian Lance Taylor <i...@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
I guess I've always seen these flags as controlling a pair of bits:
1st bit -- controls how addressing is done
2nd bit -- controls pre-emption rules
-fpie only sets the first bit (but has no effect on the second)
-fpic sets both bits.
And there are no options to clear any of the bits.
If you're going to treat them as a part of a 3-state enumeration
(standard, pic, pie) of compilation modes, then you're missing an option
-- namely one to restore the state to standard (not pic or pie).
R.
