Bug#493705: libswscale0: The library has text relocations

[Reinhard Tartler]

Russell Coker <russell at coker.com.au> writes:

> On Monday 04 August 2008 22:34, Reinhard Tartler <siretart at tauware.de> wrote:
>> Russell Coker <russell at coker.com.au> writes:
>> > The following patch fixes this.
>>
>> Are you sure that this is the only occurence of text relocations? TBH, I
>> doubt that.
>
> I built the package with the patch in question and the text relocations were 
> gone.

In libswscale. I strongly assume that there are more in the other
libraries of ffmpeg:

E: libpostproc51: shlib-with-non-pic-code usr/lib/i686/cmov/libpostproc.so.51.1.0
E: libpostproc51: shlib-with-non-pic-code usr/lib/libpostproc.so.51.1.0
E: libavutil49: shlib-with-non-pic-code usr/lib/libavutil.so.49.6.0
E: libavutil49: shlib-with-non-pic-code usr/lib/i686/cmov/libavutil.so.49.6.0
E: libavformat52: shlib-with-non-pic-code usr/lib/i686/cmov/libavformat.so.52.7.0
E: libavformat52: shlib-with-non-pic-code usr/lib/libavformat.so.52.7.0
E: libavdevice52: shlib-with-non-pic-code usr/lib/i686/cmov/libavdevice.so.52.0.0
E: libavdevice52: shlib-with-non-pic-code usr/lib/libavdevice.so.52.0.0
E: libavcodec51: shlib-with-non-pic-code usr/lib/libavcodec.so.51.50.0
E: libavcodec51: shlib-with-non-pic-code usr/lib/i686/cmov/libavcodec.so.51.50.0


>> I acknowledge that text relocations are a resonable concern, 
>> but the patch does not directly address them. It is not clear where the
>> textrelocation actually happens, and for what purpose.
>
> It happens in the .c file when it is included in the three ways that I 
> disabled.
>
> [...]  we could try and find a way of changing the assembler to need
> one less register.

indeed. please note that this discussion has occured several times on
upstream mailing list, and every time I read such a thread it endes in
blaming gcc for being too wastful wrt available registers on i386. (Yes,
ffmpeg upstream has very strong opinions on gcc and code quality here,
which makes ffmpeg a very, uhm, interesting package to maintain).

IOW: yes, such a patch would be prefererred, but is hard work, because
upstream expectations are rather high on such patches. If someone wants
to work on such a patch, feel free to attach it to this bug.

As a maintainer, I think one acceptable solution would be to provide a
replacement package that is compiled specially. However this would add
additional complexity to the package that I'm not convinced of.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4