When both -fpie and -fpic are given on the command line, -fpie wins, independent on the order of the arguments. This is unfortunate, as PIC objects are more widely usable. It would be more useful to either let the last one win, or let -fpic win over -fpie, from a usability standpoint: for example, if -fpie were added to overall CFLAGS, and those were used for both program objects and shared library objects, current build rules for many packages would most likely still work. It would've also made this patch unnecessary, as an aside: http://lists.gnu.org/archive/html/libtool/2005-11/msg00093.html Observed with gcc-3.4.4 and CVS HEAD as of before the switch to SVN. Cheers, and keep up the good work, Ralf
Hmm, I think they "combine" now: if (!opts->x_flag_opts_finished) { if (opts->x_flag_pie) opts->x_flag_pic = opts->x_flag_pie; if (opts->x_flag_pic && !opts->x_flag_pie) opts->x_flag_shlib = 1; opts->x_flag_opts_finished = true; } So, is your issue fixed?
This has been fixed by: 2012-11-13 Ian Lance Taylor <iant@google.com> * common.opt (fPIC, fPIE, fpic, fpie): Create a Negative loop such that any of these options disables the others.