> > 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.
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.zoy. org/>
--
Sam Hocevar <email address hidden> <http://