Consider this use case for an end user with 64-bit Debian 9:
- Compiles an executable with gcc, linking a few libraries like ICU,
openssl, bz2, etc. Works fine.
- Now tries to link a few of the libraries statically (e.g.,
libicuuc.a). ld blows up with a bunch of relocation R_X86_64_32S, blah
blah blah, recompile with -fPIC errors.
This was me a few hours ago, when I found about all this the hard way.
Problem is, an end user has absolutely no idea what they're doing wrong or
how to fix it. They have no idea that GCC 6 in Debian 9 now has PIE on by
default. They have no idea what PIE is. They have no idea if they must
recompile their own code with -fPIC or rebuild the 3rdparty libraries with
it. They do not believe they should have to rebuild 3rdparty libraries
(why isn't the distro's version of them working)? They also have no idea
that they can work around the problem using -no-pie if they don't care
about PIE.
All they know is that for some reason they can't link most libraries
statically without getting a bunch of weird errors. It could take hours of
research to figure out a workaround like -no-pie.
Given that GCC 6 on Debian 9 now does PIE executables by default, I think
it becomes very necessary to consider that Debian out to build all static
libraries with -fPIE (or -fPIC). Otherwise you're going to get thousands
and thousands of users having no clue why they can't link anything
statically. Plus if you did that you wouldn't have to build everything
twice. Win-Win !!! So why not?
Thanks,
Phillip
