[Ffmpeg-devel] [Patch] fix swscale shared lib on x86-64

[Michael Niedermayer]

Hi

On Mon, Sep 18, 2006 at 12:00:22PM -0400, sean wrote:
> building swscale on x86-64 fails:
> 
> /usr/bin/ld: yuv2rgb.o: relocation R_X86_64_PC32 against 
> `mmx_00ffw' can not be used when making a shared object; 
> recompile with -fPIC
> /usr/bin/ld: final link failed: Bad value
> 
> With a lot of help from the binutils list, here a patch that 
>  allows libswscale to build. It adds 
> __attribute__((visibility("hidden"))).
> 
> 
> Alan Modra < amodra at bigpond.net.au > described what the 
> problem is:
> 
> >>>mmx_00ffw is just a constant in yuv2rgb.c:
> >>>> >>
> >>>> >>uint64_t attribute_used __attribute__((aligned(8)))
> >>>> >>mmx_00ffw = 0x00ff00ff00ff00ffULL;
> 
> 
> >The trouble is that this variable is used in asm 
> statements >using rip addressing, and the variable is 
> global.  ELF >shared libraries have particular rules 
> regarding global >symbol resolution;  A global symbol in a 
> shared library may >be overridden by the same symbol in the 
> main app code (or >another shared lib).  rip addressing 
> won't work in this
> >situation for two reasons: a) the rip offset is in 
> >read-only code, so relocating the offset means the library 
> >can't share that page of text, and more seriously, b) the 
> >rip offset is only 32-bit so might not reach to the app 
> >symbol or another library sym (64-bit address space).
> 
> Works on x86-64. Dunno if it breaks anything on i386.

does -fvisibility=PROTECTED also fix this? if so id suggest to add this
to the flags if supported, this should also have other positive effects


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is