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