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

[Christopher Martin]

On September 27, 2005 03:13, Luk Claes wrote:
> Are you aware of the fact that i386 is a natural exception (doesn't need
> PIC-code to function properly) and that this piece of the policy is
> currently discussed to allow these kind (MMX) of speed optimizations for
> i386?

Hi Luk,

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.

I know that i386 works well with non-PIC code (and these optimizations 
aren't used on other architectures such as amd64, where they would cause 
problems IIUC).

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).

Cheers,
Chris