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
