Re: Static libraries - PIC or PIE?
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. :-)
>
>> 2016-10-23 10:18 GMT+02:00 Adrian Bunk <bunk@stusta.de>:
>> > Hi Bálint,
>> >
>> > there is some confusion regarding how static libraries should be
>> > compiled now.
>> >
>> > Your bugs (e.g. #837350) say "Please build libfoo.a with -fPIC".
>> >
>> > Why do these say -fPIC and not -fPIE?
>>
>> I suggest using -fPIC, because then the shared libraries would be
>> usable in shared (PIC) libraries libraries, too.
>
> you have created a lot of confusion by mixing two separate issues.
I'm sorry for creating confusion, I had absolutely no intent to cause
any. As you can see I attempted discussing every change, while in
many cases I got no response.
We also discussed the tradeoffs of using PIE or PIC in debian-devel.
>
> One of the worst examples:
> #837658 libfl-dev: Please build libfl_pic.a with -fPIC
> #841203 nmu: flex_2.6.1-1
I did not file the second one.
>
> A _pic.a library compiled without -fPIC sounds like a clear bug,
> and a binNMU that will recompile it with -fPIE won't fix that bug.
This was the single case I found with non-PIC _pic-postfixed static
library thus I see this something unique, rather than an example
of many bad cases. Recompiling would fix the FTBFS but not the
misleading prefix, indeed.
I also hoped getting response from the maintainer.
>
>> 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:
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
>
> 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.
>
>> I also suggested changing the policy #837478.
>
> Unless I misunderstand something, current policy is perfectly fine
> for the PIE change, and your claims in #837478 that building static
> libraries with -fPIC would be required for PIE binaries are not
> correct.
True, I stated more than I intended to. This was my original wording:
...
> ---
> 10.2 Libraries
> ... (paragraph about shared libs)
>
> As to the static libraries, the common case is not to have relocatable
> code, since there is no benefit, unless in specific cases; therefore the
> static version must not be compiled with the -fPIC flag. Any exception
> to this rule should be discussed on the mailing list
> debian-devel@lists.debian.org, and the reasons for compiling with the
> -fPIC flag must be recorded in the file README.Debian. [86]
>
> In other words, if both a shared and a static library is being built,
> each source unit (*.c, for example, for C files) will need to be
> compiled twice, for the normal case.
>
> ---
>
> I think with the spreading of PIE binaries the "... since there is no
> benefit ..." claim does not stand anymore. Non-PIC static libraries
> can't be linked to PIE binaries thus they are less useful for code
> sharing among packages.
>
> There is also a plan to use a specially configured GCC on several
> architectures which builds PIE binaries by default and that needs PIC
> static libraries for not statically linked binaries. [1]
...
Let me correct myself then:
...
I think with the spreading of PIE binaries the "... since there is no
benefit ..." claim does not stand anymore. Static binaries built
without either of PIC or PIE flags can't be linked to PIE binaries
nor to (PIC) shared libraries thus they are less useful for code
sharing among packages.
GCC is configured to build PIE binaries by default [1] on most
architectures and on those architectures static libraries are built
with PIE enabled. On the rest of the architectures static libraries are
still built without PIE thus the problem described in the previous
paragraph still stands.
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.
...
>
>> > 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.
>
> It would have created less confusion to not file bugs in cases where no
> maintainer action is required, ask the release team to schedule binNMUs
> for the static libraries known to need them immediately after the
> compiler change, and announce on debian-devel-announce that some
> transient build failures might be observed immediately after the
> compiler change until the binNMUs are done.
>
> I'll sort out what binNMUs are required later today.
Thank you very much for the binNMU-s and also for the work on the bugs.
>
>> I'm OK with performing binnmu-s and decreasing the severity of the 'solved'
>> bugs to wishlist.
>
> With the exception of special cases like #837658 a binNMU will
> completely solve it, and there is no point in having wishlist
> bugs for something not really permitted by policy.
I'm OK with closing the bugs since they are not critical from me, but
I think they will still be valid as wishlist bugs for the reasons
described above (non-PIE arches, linking with PIC shared libs).
Cheers,
Balint
Reply to: