Re: "PIE by default" transition is underway -- wiki needs updating

[Guillem Jover <guillem@debian.org>]

Hi!

On Tue, 2016-10-25 at 09:44:44 +0200, Bálint Réczey wrote:
> 2016-10-25 5:31 GMT+02:00 Steve M. Robbins <steve@sumost.ca>:
> > I haven't been paying close attention to the "PIE by default" [1] discussions,
> > so I may have missed the memo, but: it seems the transition is underway?
> 
> GCC have been changed to enable PIE by default but dpkg has not been
> changed yet.

Yes, this will be included in the next dpkg upload which should happen
in a couple of days.

> > I've seen two bugs already claiming "static library foo must be compiled with
> > -fPIC" -- because some reverse dependency now fails to build.  But I think
> > this advice is misplaced.  The Ubuntu page [2] says that all you need to do is
> > rebuild the library foo with the PIE-enabled compiler, then rebuild the
> > depending code:
> >
> >         Relocation Linking Failure
> >
> >         A dynamically linked program that pulls in a static library that was not
> >         built with -fPIC. These give an error like:
> >
> >             relocation R_X86_64_32 against '[SYMBOL]' can not be used when making a
> >                 shared object; recompile with -fPIC
> >
> >         To address these types of issues, the package providing the static object
> >         needs to be rebuilt (usually just a no-change rebuild against the pie-by-
> >         default compiler) before rebuilding the failed package.
> >
> >
> > So it seems to me that this should be emphasized on the wiki [1].  Secondly,
> 
> I filed the original bugs with the following template, which contains
> "Please", not
> "must": "Please build <static lib name>.a with -fPIC"
> It seems it was a mistake not emphasizing that a rebuild can also solve most of
> the FTBFS bugs, and I have now updated the wiki, too.

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. For many static libraries,
making them embeddable into other shared libraries is really not
desirable. And those should be using the shared libraries instead. 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.

> > it seems that the proposal to change policy to encourage -fPIC on static
> > libraries [3] is misplaced and should be withdrawn.    Are both these
> > statements accurate?
> 
> It have updated the wiki making it clear, that the Policy may not be
> changed.

I'd personally see no point in all those bug reports, TBH. :)

Thanks,
Guillem