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 <email@example.com>:
> > 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
Usually building everything twice is done by the build system of the
package, and debian/rules just calls $(MAKE)
> 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
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.
"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