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 <b...@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
architectures?
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
