[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Wed, Oct 26, 2016 at 08:57:52PM +0200, Andreas Cadhalpun wrote:
> Hi,
> 
> On 26.10.2016 05:26, Guillem Jover wrote:
> > On Wed, 2016-10-26 at 00:37:18 +0200, Andreas Cadhalpun wrote:
> >> On 25.10.2016 13:55, Guillem Jover wrote:
> >>> 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.
> 
> If there are more, they could be mentioned in policy, too.
> 
> > 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.
> 
> A (possibly shortened) version of this paragraph would be a good addition
> to the policy. :)
> 
> > 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!
> 
> There might be some confusion here. The ffmpeg package uses these
> static libraries only for build-time testing, so doesn't need to
> have them included in the binary packages.
> I don't know if anyone is using these shipped static libraries.
> 
> > 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.
> 
> I'd rather not built everything twice, so I think I'll just drop the
> static libraries in the next upload and only worry about this again,
> when/if someone files a bug about missing the static libraries.

It is customary to build everything twice, one with -fPIC, one without.

Waiting for a bug report to do something is unfriendly to people using
the stable release.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 


Reply to: