On Wed, Oct 26, 2016 at 12:37:18AM +0200, Andreas Cadhalpun wrote:
> The current policy says:
> "As to the static libraries, the common case is not to have relocatable code"
>
> As of gcc-6 version 6.2.0-7 this is factually wrong, because the compiler
> enables PIE by default, which means it produces relocatable code.
> This should definitely be updated to reflect reality.
It's not that simple. The compiler enables PIE by default only:
* if you use "gcc" or "gcc-6". gcc-5, clang, even gcc-snapshot still
default to non-PIE.
* on most first-class (release) architectures: amd64 arm64 armel armhf i386
mips mipsel mips64el ppc64el s390x. This leaves out powerpc.
* on none of second-class architectures: alpha hppa hurd-i386
kfreebsd-{amd64,i386} m68k powerpcspe ppc64 sh4 sparc64 x32
* on none of unofficial architectures
Points 2-4 mean you need to bear with extra joy of supporting both variants
on different archs. Point 1 means you might need to link libraries with
both into one binary.
So while indeed the current wording of the policy is wrong, the reality is
currently... complicated.
> > I still think the current policy is fine, and if someone wants to build
> > a static library with PIC it should be brought up here.
>
> The current ffmpeg packages builds shared and static libraries, the
> latter because they are used in the test suite. Both are built from
> the same object files compiled with -fPIC.
> Do you really think those static libraries should not be included
> in the binary lib*-dev packages just because they are not incompatible
> with including in other shared libraries?
What's your reason for building something as big and with as extensive
dependencies statically? Let's delegate static libraries to special needs
only, as limited as possible.
Meow!
--
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month. Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.
