[Pkg-kde-talk] Re: [Pkg-kde-commits] rev 1876 - in branches/kde-3.4.0/packages/kdemultimedia/debian: . patches

[Luk Claes]

Christopher Martin wrote:
> On September 27, 2005 03:13, Luk Claes wrote:
[...]
> I thought that "Shared libraries must be compiled with -fPIC" was intended 
> to mean that non-PIC code in a .so was not allowed anywhere, even if it 
> results from assembler optimizations, as in this case. Lintian reported 
> this problem as an error, with the following text:
> 
> E: mpeglib: shlib-with-non-pic-code usr/lib/libmpeg-0.3.0.so
> N:
> N:   The listed shared libraries contain object code that was compiled
> N:   without -fPIC. All object code in shared libraries should be
> N:   recompiled separately from the static libraries with the -fPIC option.
> N:
> N:   Another common mistake that causes this problem is linking with ``gcc
> N:   -Wl,-shared'' instead of ``gcc -shared''.
> N:
> N:   Refer to Policy Manual, section 10.2 for details.
> 
> Policy 10.2 merely reiterates the "compile with -fPIC" mantra without 
> providing further information.

Well there are already some exceptions allowed for i386. These are if
assembler optimizations are used and it FTBFS with -fPIC. If it works
with -fPIC, then it is indeed no problem to do so.

> But if I've misinterpreted the release policy (they make no mention of 
> special optimizations), could you link me to a clarification? I see the 
> recent theads on debian-policy, but they don't decisively address the 
> question. There is 
> http://lists.debian.org/debian-release/2005/07/msg00068.html, but it seems 
> to be covering a slightly different case. We could always ask the release 
> team on IRC as well.
> 
> That said, there are advantages to making it PIC on i386. Non-PIC code is a 
> disadvantage for kernels which implement ASLR, for instance. But that's a 
> pretty minor concern here, so if we can get policy clarified, and people 
> prefer to keep the optimizations (and revert my changes), then that's quite 
> fine with me. In my experience these sort of optimizations are surprisingly 
> ineffectual (I yanked MMX optimizations out of another multimedia package, 
> and noticed not the slightest shred of difference, nor has anyone else 
> bothered to complain).

So indeed it shouldn't be reverted. Though I think you don't have to
invest time to let things compile with PIC on i386...

Cheers

Luk