libmpeg2-4: Non-PIC shared library

[Debian Bug Importer]

Automatically imported from Debian bug report #268603 http://bugs.debian.org/268603

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #268603 http://bugs.debian.org/268603

[Debian Bug Importer (debzilla)]

Message-Id: <20040828105847.7B3D643C04@doctormoo>
Date: Sat, 28 Aug 2004 06:58:47 -0400
From: Nathanael Nerode <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: libmpeg2-4: Non-PIC shared library

Package: libmpeg2-4
Version: 0.4.0b-2
Severity: serious
Justification: 5.f (Sarge RC showstoppers)

libmpeg2.so.0 has a TEXTREL entry. This means that it contains non-PIC code
and can't be prelinked against.

Policy requires that shared libraries are compiled with -fPIC. (Unless
there's a really really good excuse, of course.)

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8.ncn.1
Locale: LANG=C, LC_CTYPE=C

Versions of packages libmpeg2-4 depends on:
ii libc6 2.3.2.ds1-16 GNU C Library: Shared libraries an

-- no debconf information

[Tollef Fog Heen (tfheen)]

21:52 < Mithrandir> mdz: 896 seems ok, the TEXTREL segment is only present on i386
21:53 < Mithrandir> mdz: so, technically, it's a policy violation, but we can
ignore it, as it's
                    correct on amd64.
21:53 < Mithrandir> (and i386 doesn't care)
21:53 < mdz> fascinating
21:53 < Mithrandir> : tfheen@golem(golem-i386) ~ > objdump -x
/usr/lib/libmpeg2.so.0| grep TEXT
21:53 < Mithrandir> TEXTREL 0x0
21:53 < Mithrandir> vs
21:53 < Mithrandir> : tfheen@golem(golem-amd64) ~ > objdump -x
/usr/lib/libmpeg2.so.0| grep TEXT
21:53 < Mithrandir> : tfheen@golem(golem-amd64) ~ >
21:53 < Mithrandir> just close the bug with FIXED and a comment?
22:19 < mdz> NOTWARTY and a comment
22:19 < mdz> it's still a bug in Debian

[David I. Lehn (dil)]

* Nathanael Nerode <email address hidden> [2004-08-28T07:14:15-0400]:
> Package: libmpeg2-4
> Version: 0.4.0b-2
> Severity: serious
> Justification: 5.f (Sarge RC showstoppers)
>
> libmpeg2.so.0 has a TEXTREL entry. This means that it contains non-PIC code
> and can't be prelinked against.
>
> Policy requires that shared libraries are compiled with -fPIC. (Unless
> there's a really really good excuse, of course.)
>

-fPIC is not used for performance reasons. On older machines it can
make the difference between being able to decode a dvd or not. On newer
faster machines it probably doesn't matter as much. For one reason or
another it seems the only remaining architectures that can deal without
-fPIC are i?86 and k?. Is there anyway around the prelinking issue that
would allow non-PIC code to be used? It would be unfortunate to have to
cripple a library that is so well optimized.

-dave

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 31 Aug 2004 13:10:31 -0400
From: "David I. Lehn" <email address hidden>
To: Nathanael Nerode <email address hidden>, <email address hidden>
Subject: Re: Bug#268603: libmpeg2-4: Non-PIC shared library

* Nathanael Nerode <email address hidden> [2004-08-28T07:14:15-0400]:
> Package: libmpeg2-4
> Version: 0.4.0b-2
> Severity: serious
> Justification: 5.f (Sarge RC showstoppers)
>
> libmpeg2.so.0 has a TEXTREL entry. This means that it contains non-PIC code
> and can't be prelinked against.
>
> Policy requires that shared libraries are compiled with -fPIC. (Unless
> there's a really really good excuse, of course.)
>

-fPIC is not used for performance reasons. On older machines it can
make the difference between being able to decode a dvd or not. On newer
faster machines it probably doesn't matter as much. For one reason or
another it seems the only remaining architectures that can deal without
-fPIC are i?86 and k?. Is there anyway around the prelinking issue that
would allow non-PIC code to be used? It would be unfortunate to have to
cripple a library that is so well optimized.

-dave

[Sam Hocevar (sam-h)]

On Tue, Aug 31, 2004, David I. Lehn wrote:

> > libmpeg2.so.0 has a TEXTREL entry. This means that it contains non-PIC code
> > and can't be prelinked against.
> >
> > Policy requires that shared libraries are compiled with -fPIC. (Unless
> > there's a really really good excuse, of course.)
>
> -fPIC is not used for performance reasons.

   Well, if the library is not PIC, it's not a shared library since the
text segment cannot be shared. Concurrent processes will each have to
load a separate instance of the library.

> On older machines it can
> make the difference between being able to decode a dvd or not.

   What would be the specs of such machines? Most critical routines
in libmpeg2 have MMX equivalents, and I don't know of any non-MMX x86
machine that can decode a DVD.

> faster machines it probably doesn't matter as much. For one reason or
> another it seems the only remaining architectures that can deal without
> -fPIC are i?86 and k?. Is there anyway around the prelinking issue that
> would allow non-PIC code to be used?

   No.

> It would be unfortunate to have to cripple a library that is so well
> optimized.

   Blame the x86 architecture for having so few registers. The static
version of the library will work at full speed, though.

Sam.
--
Sam Hocevar <email address hidden> <http://sam.zoy.org/>

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 10 Sep 2004 14:53:03 +0200
From: Sam Hocevar <email address hidden>
To: "David I. Lehn" <email address hidden>
Cc: Nathanael Nerode <email address hidden>, <email address hidden>
Subject: Re: Bug#268603: libmpeg2-4: Non-PIC shared library

On Tue, Aug 31, 2004, David I. Lehn wrote:

> > libmpeg2.so.0 has a TEXTREL entry. This means that it contains non-PIC code
> > and can't be prelinked against.
> >
> > Policy requires that shared libraries are compiled with -fPIC. (Unless
> > there's a really really good excuse, of course.)
>
> -fPIC is not used for performance reasons.

   Well, if the library is not PIC, it's not a shared library since the
text segment cannot be shared. Concurrent processes will each have to
load a separate instance of the library.

> On older machines it can
> make the difference between being able to decode a dvd or not.

   What would be the specs of such machines? Most critical routines
in libmpeg2 have MMX equivalents, and I don't know of any non-MMX x86
machine that can decode a DVD.

> faster machines it probably doesn't matter as much. For one reason or
> another it seems the only remaining architectures that can deal without
> -fPIC are i?86 and k?. Is there anyway around the prelinking issue that
> would allow non-PIC code to be used?

   No.

> It would be unfortunate to have to cripple a library that is so well
> optimized.

   Blame the x86 architecture for having so few registers. The static
version of the library will work at full speed, though.

Sam.
--
Sam Hocevar <email address hidden> <http://sam.zoy.org/>

[Frank Lichtenheld (djpig)]

On Tue, Aug 31, 2004 at 01:10:31PM -0400, David I. Lehn wrote:
> * Nathanael Nerode <email address hidden> [2004-08-28T07:14:15-0400]:
> > libmpeg2.so.0 has a TEXTREL entry. This means that it contains non-PIC code
> > and can't be prelinked against.
> >
> > Policy requires that shared libraries are compiled with -fPIC. (Unless
> > there's a really really good excuse, of course.)
> >
>
> -fPIC is not used for performance reasons. On older machines it can
> make the difference between being able to decode a dvd or not. On newer
> faster machines it probably doesn't matter as much. For one reason or
> another it seems the only remaining architectures that can deal without
> -fPIC are i?86 and k?. Is there anyway around the prelinking issue that
> would allow non-PIC code to be used? It would be unfortunate to have to
> cripple a library that is so well optimized.

What's the status of this bug? From my pov there is currently no
other solution than to actually use -fPIC ...
or am I overlooking something?

Gruesse,
--
Frank Lichtenheld <email address hidden>
www: http://www.djpig.de/

[Debian Bug Importer (debzilla)]

Message-ID: <20041003003713.GC25452@feynman>
Date: Sun, 3 Oct 2004 02:37:13 +0200
From: Frank Lichtenheld <email address hidden>
To: "David I. Lehn" <email address hidden>, <email address hidden>
Cc: Nathanael Nerode <email address hidden>
Subject: Re: Bug#268603: libmpeg2-4: Non-PIC shared library

On Tue, Aug 31, 2004 at 01:10:31PM -0400, David I. Lehn wrote:
> * Nathanael Nerode <email address hidden> [2004-08-28T07:14:15-0400]:
> > libmpeg2.so.0 has a TEXTREL entry. This means that it contains non-PIC code
> > and can't be prelinked against.
> >
> > Policy requires that shared libraries are compiled with -fPIC. (Unless
> > there's a really really good excuse, of course.)
> >
>
> -fPIC is not used for performance reasons. On older machines it can
> make the difference between being able to decode a dvd or not. On newer
> faster machines it probably doesn't matter as much. For one reason or
> another it seems the only remaining architectures that can deal without
> -fPIC are i?86 and k?. Is there anyway around the prelinking issue that
> would allow non-PIC code to be used? It would be unfortunate to have to
> cripple a library that is so well optimized.

What's the status of this bug? From my pov there is currently no
other solution than to actually use -fPIC ...
or am I overlooking something?

Gruesse,
--
Frank Lichtenheld <email address hidden>
www: http://www.djpig.de/

[Andreas Barth (aba)]

Hi,

I discussed this issue with Thiemo to get a bit more clue about what the
possible technical issues are.

1. non-PIC shared libs are completly broken e.g. on mips, as the ABI
just doesn't support it (it's the same more or less on all !i386 archs).
2. non-PIC means: If two programs use this lib in parallel, two
instances of the lib needs to be loaded. This can negate the performance
boost of the extra register by increased cache pressure.
3. non-PIC has one advantage over statically compiled: It doesn't
require a rebuild of depending applications if a security issue is found
in the lib.

Cheers,
Andi
--
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 20 Oct 2004 16:02:06 +0200
From: Andreas Barth <email address hidden>
To: <email address hidden>
Subject: PIC vs non-PIC

Hi,

I discussed this issue with Thiemo to get a bit more clue about what the
possible technical issues are.

1. non-PIC shared libs are completly broken e.g. on mips, as the ABI
just doesn't support it (it's the same more or less on all !i386 archs).
2. non-PIC means: If two programs use this lib in parallel, two
instances of the lib needs to be loaded. This can negate the performance
boost of the extra register by increased cache pressure.
3. non-PIC has one advantage over statically compiled: It doesn't
require a rebuild of depending applications if a security issue is found
in the lib.

Cheers,
Andi
--
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

[Andreas Barth (aba)]

tag 268603 +sarge-ignore
thanks

Hi,

I think we don't need to discuss about non-PIC for !i386 - this would be
plainly broken. But, as you told us, on !i386 the bug is not existent
(and looking at mips and alpha revealed no TEXTREL-section, so this
matches). So, this is not an issue in this case (but I remarked it if a
similar bugs happens to hit us, so that we remember in that case).

For i386, using non-PIC in a shared lib is in general a RC bug. But, in
this case the maintainers decision for not using it has reasons. Of
course, we need to discuss whether there are better ways to achive it,
without breaking policy. Implementing it as static lib comes to my mind
for that. However, I'd like a broader discussion, including input from
the security team, on using a static lib. Therefore, for the time scale
of sarge, there is probably no better solution available, and I'm
marking this bug as sarge-ignore.

Of course, please still feel free to fix it. ;)

Cheers,
Andi
--
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 20 Oct 2004 22:38:55 +0200
From: Andreas Barth <email address hidden>
To: <email address hidden>
Subject: For i386, this issue could be clarified after release of sarge

tag 268603 +sarge-ignore
thanks

Hi,

I think we don't need to discuss about non-PIC for !i386 - this would be
plainly broken. But, as you told us, on !i386 the bug is not existent
(and looking at mips and alpha revealed no TEXTREL-section, so this
matches). So, this is not an issue in this case (but I remarked it if a
similar bugs happens to hit us, so that we remember in that case).

For i386, using non-PIC in a shared lib is in general a RC bug. But, in
this case the maintainers decision for not using it has reasons. Of
course, we need to discuss whether there are better ways to achive it,
without breaking policy. Implementing it as static lib comes to my mind
for that. However, I'd like a broader discussion, including input from
the security team, on using a static lib. Therefore, for the time scale
of sarge, there is probably no better solution available, and I'm
marking this bug as sarge-ignore.

Of course, please still feel free to fix it. ;)

Cheers,
Andi
--
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

[Loïc Minier (lool)]

        Hi,

On mer, oct 20, 2004, Andreas Barth wrote:
> I think we don't need to discuss about non-PIC for !i386 - this would be
> plainly broken. But, as you told us, on !i386 the bug is not existent
> (and looking at mips and alpha revealed no TEXTREL-section, so this
> matches). So, this is not an issue in this case (but I remarked it if a
> similar bugs happens to hit us, so that we remember in that case).
>
> For i386, using non-PIC in a shared lib is in general a RC bug. But, in
> this case the maintainers decision for not using it has reasons. Of
> course, we need to discuss whether there are better ways to achive it,
> without breaking policy. Implementing it as static lib comes to my mind
> for that. However, I'd like a broader discussion, including input from
> the security team, on using a static lib. Therefore, for the time scale
> of sarge, there is probably no better solution available, and I'm
> marking this bug as sarge-ignore.

 After discussion with upstream, PIC versus non-PIC is something like
 10% difference in performance. Upstream wondered why it would an issue
 to use PIC under i386 only, so I will seek clarification on why the
 policy has such a requirement. If the requirement is only there to
 protect against the level of support of non-PIC under !i386, which
 would be strange, then I suppose it's ok to keep shipping the lib with
 non-PIC under i386.

 If the policy has some other justification, PIC will be used and
 static libs will always be available for end-user apps to build with so
 that full performance can be achieved.

   Bye,

--
Loïc Minier <email address hidden>

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 17 Sep 2005 11:36:21 +0200
From: =?iso-8859-1?Q?Lo=EFc?= Minier <email address hidden>
To: Andreas Barth <email address hidden>
Cc: <email address hidden>
Subject: Re: For i386, this issue could be clarified after release of sarge

        Hi,

On mer, oct 20, 2004, Andreas Barth wrote:
> I think we don't need to discuss about non-PIC for !i386 - this would b=
e
> plainly broken. But, as you told us, on !i386 the bug is not existent
> (and looking at mips and alpha revealed no TEXTREL-section, so this
> matches). So, this is not an issue in this case (but I remarked it if a
> similar bugs happens to hit us, so that we remember in that case).
>=20
> For i386, using non-PIC in a shared lib is in general a RC bug. But, in
> this case the maintainers decision for not using it has reasons. Of
> course, we need to discuss whether there are better ways to achive it,
> without breaking policy. Implementing it as static lib comes to my mind
> for that. However, I'd like a broader discussion, including input from
> the security team, on using a static lib. Therefore, for the time scale
> of sarge, there is probably no better solution available, and I'm
> marking this bug as sarge-ignore.

 After discussion with upstream, PIC versus non-PIC is something like
 10% difference in performance. Upstream wondered why it would an issue
 to use PIC under i386 only, so I will seek clarification on why the
 policy has such a requirement. If the requirement is only there to
 protect against the level of support of non-PIC under !i386, which
 would be strange, then I suppose it's ok to keep shipping the lib with
 non-PIC under i386.

 If the policy has some other justification, PIC will be used and
 static libs will always be available for end-user apps to build with so
 that full performance can be achieved.

   Bye,

--=20
Lo=EFc Minier <email address hidden>

[Loïc Minier (lool)]

block #268603 with #329762
thanks

--
Loïc Minier <email address hidden>
"What do we want? BRAINS! When do we want it? BRAINS!"

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 30 Oct 2005 15:12:20 +0100
From: Loic Minier <email address hidden>
To: <email address hidden>
Subject: block #268603 with #329762

block #268603 with #329762
thanks

--=20
Lo=EFc Minier <email address hidden>
"What do we want? BRAINS! When do we want it? BRAINS!"

[Loïc Minier (lool)]

# I'll close this bug by switching to the new Standards-Version in the
# next upload, no need to NMU, thanks.
tag 268603 + pending
severity 268603 important
stop

--
Loïc Minier <email address hidden>

[Nathanael Nerode (neroden-twcny)]

submitter 370186 <email address hidden>
submitter 212522 <email address hidden>
submitter 243022 <email address hidden>
submitter 328180 <email address hidden>
submitter 335631 <email address hidden>
submitter 336878 <email address hidden>
submitter 345282 <email address hidden>
submitter 368558 <email address hidden>
submitter 368562 <email address hidden>
submitter 368565 <email address hidden>
submitter 244162 <email address hidden>
submitter 211748 <email address hidden>
submitter 330635 <email address hidden>
submitter 335633 <email address hidden>
submitter 345420 <email address hidden>
submitter 366171 <email address hidden>
submitter 370656 <email address hidden>
submitter 370664 <email address hidden>
# crafted is gone
close 235258
submitter 321803 <email address hidden>
submitter 342261 <email address hidden>
submitter 343322 <email address hidden>
# queue is gone
close 321184
submitter 346055 <email address hidden>
submitter 346056 <email address hidden>
submitter 346059 <email address hidden>
submitter 346377 <email address hidden>
submitter 367465 <email address hidden>
submitter 235498 <email address hidden>
submitter 329852 <email address hidden>
submitter 333967 <email address hidden>
submitter 333968 <email address hidden>
submitter 335986 <email address hidden>
submitter 366578 <email address hidden>
submitter 342159 <email address hidden>
submitter 329845 <email address hidden>
submitter 268603 <email address hidden>
# Bugs fixed in NMUs
close 346058 0.9.6-0.9
close 331271 2.6.0-1.2
close 335635 2.2-2.2
close 346172 1.0.20040603-1.2
close 345281 1.10-1.1
close 344230 1.34-7.2
close 342780 2.6.13+0rc3-2.1
close 337362 1.2-7.3
close 335955 3.0.4-9.1
close 335293 0.4-1.1
close 333974 2.3.3-6.1
close 332832 0.2.2-1.1
close 236117 0.8.7-1.2
close 236116 0.95-4.1
close 341669 2.0.9-3.1
close 328176 0.2.1-2.1
close 328175 20021127-4.1
thanks

[Loïc Minier (lool)]

# Automatically generated email from bts, devscripts version 2.10.11
package libmpeg2-4 libmpeg2-4-dev mpeg2dec
tags 268603 + pending
tags 390931 + pending

[Loïc Minier (lool)]

# Automatically generated email from bts, devscripts version 2.10.11
package libmpeg2-4 libmpeg2-4-dev mpeg2dec
tags 268603 + pending
tags 390931 + pending
tags 407922 + pending

[Loïc Minier (lool)]

# Automatically generated email from bts, devscripts version 2.10.11
package libmpeg2-4 libmpeg2-4-dev mpeg2dec
tags 268603 + pending
tags 390931 + pending
tags 403194 + pending
tags 407922 + pending