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

Re: Static libraries - PIC or PIE?

2016-10-23 16:06 GMT+02:00 Adrian Bunk <bunk@stusta.de>:
> 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?

Enabling PIC seemed more straightforward to me than asking for PIC
shared libraries and PIE static libraries. With GCC defaulting to PIE
this is easy, but at the beginning it seemed that only a smaller
subset of the architectures was going to use PIE by default.

> 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
> architectures?

AFAIK the porters needed to opt-in which makes sense to me:


> In any case, this would not provide any kind of reason for requiring
> to build static libraries with PIC.
>> Cheers,
>> Balint
> cu
> Adrian
> --
>        "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: