Bug#837478: "PIE by default" transition is underway -- wiki needs updating

[Guillem Jover <guillem@debian.org>]

Hi!

On Wed, 2016-10-26 at 00:37:18 +0200, Andreas Cadhalpun wrote:
> On 25.10.2016 13:55, Guillem Jover wrote:
> > I don't think the reasoning there is sound (as I've mentioned
> > elsewhere), and the policy bug should be closed.
> > 
> > Switching from no-PIE to PIE by default preserves our current behavior
> > WRT static libraries vs shared libraries.
> 
> The current policy says:
> "As to the static libraries, the common case is not to have relocatable code"
> 
> As of gcc-6 version 6.2.0-7 this is factually wrong, because the compiler
> enables PIE by default, which means it produces relocatable code.
> This should definitely be updated to reflect reality.

Right, that should be updated, but the bug was not about that. :)

My point was that, yes we have changed to generating relocatable code
but that is still targetted for executables only, which preserves the
current behavior, sorry if the wording was confusing.

> > For many static libraries,
> > making them embeddable into other shared libraries is really not
> > desirable. And those should be using the shared libraries instead.
> 
> If that's the reason why it shouldn't be done, policy should mention it.
> The current policy does not list this as reason not to use -fPIC, merely:
> "since there is no benefit"

I don't think it's "the reason", but personally I think it's one
important reason.

Embedding static libraries into shared libraries can be very
problematic if the shared libraries do not take precautions, such as
explicit symbol visibility or symbol versioning, etc. Which most
shared libraries do not do. And even then it's still prone to symbol
conflicts, etc, even inside the shared library being linked itself in
case of namespace issues, if the static library is sloppy.

So I think this should be in general discouraged.

> > I still think the current policy is fine, and if someone wants to build
> > a static library with PIC it should be brought up here.
> 
> The current ffmpeg packages builds shared and static libraries, the
> latter because they are used in the test suite. Both are built from
> the same object files compiled with -fPIC.
> Do you really think those static libraries should not be included
> in the binary lib*-dev packages just because they are not incompatible
> with including in other shared libraries?

Well, I guess depends on how "clean" they are, what's the intended
usage, etc. But given that in this case the usage is inside the same
project, that seems pretty safe! I'd personally probably not ship them,
and would instead provide non-PIC ones there. Or at most ship them in
addition as _pic.a libraries, to require explicit invocation.

Thanks,
Guillem