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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christopher Martin wrote:
> Author: chrsmrtn
> Date: 2005-09-27 01:50:34 +0000 (Tue, 27 Sep 2005)
> New Revision: 1876
> 
> Added:
>   
branches/kde-3.4.0/packages/kdemultimedia/debian/patches/13_mpeglib_PIC.diff
> Modified:
>    branches/kde-3.4.0/packages/kdemultimedia/debian/changelog
>   
branches/kde-3.4.0/packages/kdemultimedia/debian/patches/98_buildprep.diff
> Log:
> mpeglib noopt fix.
> 
> 
> Modified: branches/kde-3.4.0/packages/kdemultimedia/debian/changelog
> ==================================================================> ---
branches/kde-3.4.0/packages/kdemultimedia/debian/changelog	2005-09-26 22:00:57
UTC (rev 1875)
> +++ branches/kde-3.4.0/packages/kdemultimedia/debian/changelog	2005-09-27
01:50:34 UTC (rev 1876)
> @@ -1,3 +1,13 @@
> +kdemultimedia (4:3.4.2-3) UNRELEASED; urgency=low
> +
> +  +++ Changes by Christopher Martin:
> +
> +  * Add a patch which disables MMX optimizations in the mpeglib package
for
> +    the i386 architecture. These were causing the library to contain
non-PIC
> +    code, a violation of the release policy.
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?

Cheers

Luk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDOPEz5UTeB5t8Mo0RAtjDAJ0e8f8on/86aiB/QPbEH1MRWVYMcACdF1Kl
ohkRsDRDK79jEl3K0rgs6sY=PYSx
-----END PGP SIGNATURE-----

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

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