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

Re: Static libraries - PIC or PIE?

On Sun, Oct 23, 2016 at 03:17:06PM +0200, Bálint Réczey wrote:
> Hi Adrian,
> 2016-10-23 13:26 GMT+02:00 Adrian Bunk <bunk@stusta.de>:
> > On Sun, Oct 23, 2016 at 12:29:42PM +0200, Bálint Réczey wrote:
> >> Hi Ardian,
> >
> > Hi Bláint, ;-)
> I'm sorry. :-)

No problem. :-)

> >> This in many cases also simplify debian/rules.
> >
> > No, it would actually make building static libraries a real pain.
> Could you please show an example?
> I went trough many packages and adding -fPIC was really
> straight-forward every time. OTOH packages providing both
> shared and static libraries build some parts twice like in antlr's
> case:

Usually building everything twice is done by the build system of the 
package, and debian/rules just calls $(MAKE)

> build-stamp:
>     dh_testdir
>     uudecode -o debian/antlr.snk debian/antlr.snk.uue
>     $(MAKE) -f debian/Makefile.debian compile build_antlr
>     $(MAKE) -C lib/cpp CXXFLAGS="+ -fPIC -DPIC"
>     mv -f lib/cpp/src/libantlr.a debian/libantlr-pic.a
>     $(MAKE) -C lib/cpp clean
>     $(MAKE) -C lib/cpp
>     touch build-stamp

That's a good example why this is a real pain.

You really don't want to force maintainers to dissect the build of their 
packages, especially in the normal case where just calling $(MAKE) was
working without your proposed requirement.

Just passing normal CFLAGS from dpkg-buildflags through the package 
build to the compiler is still not working in a huge number of packages 
after years, and this would be worse by several orders of magnitude.

> > Think of a normal source package building shared libraries,
> > static libraries and some programs.
> >
> > How do you want to tell the build system of the package that it should
> > build the static libraries with -fPIC, but not the programs?
> It is usually already done by upstream or at least in packaging
> since we require -fPIC for shared libs.

You are completely wrong on that.

-fPIC is required and used for shared libraries.
Static libraries compiled with -fPIC are *very* rare.

Compiling with -fPIC for the shared library and without -fPIC for the 
static library is the one and (usually) only reason why all objects
are compiled twice when building libraries.

> I assume non-PIC static library used in a PIC shared library is the
> specific case mentioned in the original text, which still does not
> work on any architecture.

Why do you want to forvce maintainers to go through great pain to get 
that working?

It is usually a bug when you end up linking a static library into a 
shared library, and in addition to a performance penalty you would
lose the benefit of getting a build failure for such bugs.

There are some rare cases of packages not building shared libraries. 
There might be other exotic situations where linking a static library 
into a shared library makes sense.
Requiring discussion of these on a case-by-case basis on debian-devel
as policy requires sounds pretty appropriate to me.

> >> > My current understanding is that a binNMU would recompile the the static
> >> > library with PIE (not PIC), and that this is sufficient.
> >>
> >> In most of the cases this would be sufficient, but at the time I filed the
> >> bugs the default was -no-pie, thus it was not an option.
> >
> > It is clear that the binNMUs have to happen after the change.
> Yes, it was expected, but I think the changes would still be
> useful on architectures not enabling PIE because they allow
> enabling pie in reverse dependencies selectively.

Is there actually a good reason why PIE was only enabled on the release

In any case, this would not provide any kind of reason for requiring 
to build static libraries with PIC.

> Cheers,
> Balint



       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply to: