Sune Vuorela <nos...@vuorela.dk> writes: > One of my upstreams of a collection of shared libraries is about to make > a change that is going to require all executables built against these > shared libraries to be built with -fPIE (and libraries with -fPIC).
> Is there anything I should be aware of? First, the bit that you already know, but saying it for the record here: Libraries with -fPIC is, of course, already expected. There are only a few exceptions for speed reasons on register-constrained architectures. I'd generally say that if the library isn't so performance-critical that the maintainers consider reimplementing parts of it in hand-coded assembly, just always use -fPIC. For PIE, the main practical problem with PIE is that PIE and PIC conflict, so you can't just add -fPIE to the compiler flags of a package that builds both executables and libraries. That's the only reason why I'm not now building all of my binaries PIE. So I think there's no problem with just going along with upstream on this change; more and more of the archive is going to be built PIE anyway as hardening flags slowly make their way into our packages. Both consume a register on i386, which is a problem because i386 is ridiculously register-constrained. But it's not a significant issue on amd64, which the trend lines all say is the direction everything is going anyway. Debian doesn't currently do prelinking; Red Hat does (optionally), and it's extremely annoying for intrusion detection software like Tripwire, since the prelinking goes through and changes installed files and now the checksums don't match. That's the main reason why I'm not sure prelinking is worth it; I'll take the speed hit from using non-prelinked binaries in exchange for verifiable checksums. (Of course, it would be great to have both.) > A bit of background: > http://www.macieira.org/blog/2012/01/sorry-state-of-dynamic-libraries-on-linux/ > http://www.macieira.org/blog/2012/01/update-and-benchmark-on-the-dynamic-library-proposals/ These are excellent, and a good companion to Ulrich Drepper's paper (also linked there). They go over good C shared library behavior; some of those techniques (like hidden visibility for internal symbols and -Bsymbolic) I've been using for some of my shared libraries for years now. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ty3ew0p3....@windlord.stanford.edu
