[ subject adjusted a bit; and sorry for the long post ] * Paul Jakma wrote on Tue, Nov 29, 2005 at 07:59:40AM CET: > On Tue, 29 Nov 2005, Ralf Wildenhues wrote: > > >As far as I can see it, libtool could support PIE reasonably well by > >simply: *snip*
Scratch the first suggestion. I've been testing a bit. > >Second possibility: the user could have created main.lo and linked that > >directly into the program, although he shouldn't. So let's fix above to > >- ignoring completely -pie -fpie during compilation of the PIC object, > > if any, but applying it to the non-PIC object, if any. > >- ignoring both during linking of a library > >- not ignoring both when linking a program > > Right. This seems to me the superior solution. Thus, let's kill the --with-pic idea, too. It won't get us over main.o compiled-without-libtool and neither one of -fpic or -fpie in CFLAGS anyway. And I can't see why it should be more useful to have two PIC objects rather than one PIC and one PIE object. > >Remaining questions: > >- some projects employ assembler hackery that relies on, and creates > > different code, depending upon -DPIC. They'll probably have to > > adjust, but in any case it may be nice for them to know. Does -fpie > > #define something they can use? AFAIK there isn't. gcc defines __PIC__, __pic__. Thus one open question would be whether we should notify the compiler/assembler that PIE code is created. We could `-DPIC -DPIE', for example (PIC because most assembler code will likely work unmodified from the PIC version, see http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00145.html ). Or, to not avoid further namespace invasion, maybe `-DPIC -DLT_PIE'. For CC and CXX tags? Suggestions? Maybe only add -DPIC? One weak reason against adding anything would be the fact that non-libtool created PIE objects would not see the define either. :-/ (Actually, that could be interpreted as reason for the program author to rely on __PIC__ or __pic__ iff this is gcc-specific code anyway.) > >- How portable is this whole thing? I mean, does PIE work on AIX, where > > we do not even create non-PIC objects? > > I think it needs runtime dynamic linker support, otherwise you can > not execute the resulting binary ;). Well. It's implemented in GNU binutils ld as of recently enough, GCC as of recently enough, and with them is said to work on all ELF systems. Any other ones? Does the Solaris linker support it, for example? Do other linkers plan to support it? Any compilers/linkers on which -pie/-fpie/-fPIE are spelled differently? Is there an easy test we can use to find out whether it works? My tests with gcc-3.4.4 show that -fpie/-fPIE always override -fpic/-fPIC, independent of the order in which they were passed. (What an unfortunate choice, by the way. Oh well.) > >Sure. I believe my scheme outlined above, implemented in libtool, > >would simply solve all your problems. Right? What's missing? > > I think it would, yes, just about - if you compile PIC at least. So, let's summarize our current best bet: User does something like: configure LDFLAGS=-pie CFLAGS=-fpie CXXFLAGS=-fpie \ FFLAGS=-fpie FCFLAGS=-fpie [...] make make install when she already knows that PIE is supported. Libtool then does this (implemented in patch below): - strip -pie/-fpie/-fPIE from compile flags for PIC objects and from LTCFLAGS for compilation of the symfile object as that one should be PIC (I believe stripping from LTCC is not needed: putting `-pie' in CC will break creating shared libraries; don't do that). - strip -pie/-fpie/-fPIE from link flags for libraries, but not for programs: actually, this needs no changes; libtool already does exactly the right thing here. Probably there will be more fallout: third-party configure tests may assume CFLAGS and LDFLAGS may also be used when creating shared objects A temporary workaround for such breakage may be to try configure make LDFLAGS=-pie CFLAGS=-fpie [...] instead. But then, configure won't always be able to draw the correct conclusions either. So please report any such breakage you encounter, so it can be fixed. I'd be glad if someone could test CVS HEAD with the patch below on a bunch of packages, and/or with the Libtool test suite. Backporting to ltmain.in of branch-1-5 is rather easy. Also, it would be great if someone could write nice documentation for this (hint, hint ;-). OTOH, I probably won't want to apply the patch just yet. I would like to learn a bit more about possible pitfalls in this area. What if the compiler specs are changed to do PIE by default? Can we regress there in any way? (I think not, but better be sure and test this.) What if we later decide we want this whole PIE business integrated tightly into libtool works (as we do PIC now)? On GNU/Linux, x86_64, the test suite fares pretty good: - the F77, FC, GCJ tests fail or skip, presumably(?) because g77-3.4.4, gfortran-4.0.0 and gcj-3.4.4 are not ready for either PIE or (I still need to check with a newer version). - `-static' is correctly detected as unsupported. - You could even use `--disable-static', and it will do what you expect it to: use the libtool-created PIC objects everywhere, and the non- libtool-created PIE ones. :) - The test for pic_flag in libtool.m4 succeeds, but strictly speaking, it tests the wrong thing by not eliminating the -fpie in the resulting flags `-fpie -fpic'. Oh well. Cheers, Ralf Basic support for PIE (position-independent executables). * libltdl/config/ltmain.m4sh (func_generate_dlsyms): Don't pass PIE flag for compilation of the symbol file object. (func_mode_compile): Pass PIE flag only for non-PIC objects. Index: libltdl/config/ltmain.m4sh =================================================================== RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v retrieving revision 1.21 diff -u -r1.21 ltmain.m4sh --- libltdl/config/ltmain.m4sh 25 Nov 2005 18:13:53 -0000 1.21 +++ libltdl/config/ltmain.m4sh 29 Nov 2005 19:25:30 -0000 @@ -968,9 +968,16 @@ esac ;; esac + symtab_cflags= + for arg in $LTCFLAGS; do + case $arg in + -pie | -fpie | -fPIE) ;; + *) symtab_cflags="$symtab_cflags $arg" ;; + esac + done # Now compile the dynamic symbol file. - func_show_eval '(cd $output_objdir && $LTCC $LTCFLAGS -c$no_builtin_flag$pic_flag_for_symtable "$my_dlsyms")' 'exit $?' + func_show_eval '(cd $output_objdir && $LTCC$symtab_cflags -c$no_builtin_flag$pic_flag_for_symtable "$my_dlsyms")' 'exit $?' # Clean up the generated files. func_show_eval '$RM "$output_objdir/$my_dlsyms" "$nlist" "${nlist}S" "${nlist}T"' @@ -1108,6 +1115,7 @@ arg_mode=normal libobj= later= + pie_flag= for arg do @@ -1134,6 +1142,11 @@ continue ;; + -pie | -fpie | -fPIE) + pie_flag="$pie_flag $arg" + continue + ;; + -shared | -static | -prefer-pic | -prefer-non-pic) later="$later $arg" continue @@ -1423,7 +1436,7 @@ if test "$build_old_libs" = yes; then if test "$pic_mode" != yes; then # Don't build PIC code - command="$base_compile $qsrcfile" + command="$base_compile $qsrcfile$pie_flag" else command="$base_compile $qsrcfile $pic_flag" fi _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
