[FFmpeg-devel] [PATCH] set HAVE_MMX2 in config.h

[Diego Biurrun]

On Wed, Mar 19, 2008 at 01:34:23AM -0400, Alexander Strange wrote:
> On Wed, Mar 19, 2008 at 1:08 AM, Alexander Strange
> <astrange at ithinksw.com> wrote:
> >
> > On Tue, Mar 18, 2008 at 11:03 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >  >
> >  > On Tue, Mar 18, 2008 at 10:37:34PM -0400, Alexander Strange wrote:
> >  >  >
> >  >  > On Mar 18, 2008, at 5:57 PM, Gert Vervoort wrote:
> >  >  >>
> >  >  >> Enabling HAVE_MMX2 for swscale gives an linker error on x86-64 when
> >  >  >> compiling as a shared library:
> >  >  >>
> >  >  >> gcc -shared -Wl,-soname,libswscale.so.0 -L"/tmp/ffmpeg"/libavutil
> >  >  >> -rdynamic -export-dynamic -Wl,--warn-common -Wl,--as-needed
> >  >  >> -Wl,-rpath-link,"/tmp/ffmpeg"/libavcodec
> >  >  >> -Wl,-rpath-link,"/tmp/ffmpeg"/libavformat
> >  >  >> -Wl,-rpath-link,"/tmp/ffmpeg"/libavutil -Wl,-Bsymbolic -o
> >  >  >> libswscale.so.0 rgb2rgb.o swscale.o yuv2rgb.o -lavutil -lz -pthread -lm
> >  >  >> -lamrnb -lm -lamrwb -lm -lfaac -lfaad -lmp3lame -lm   -ldl -ldl -lX11
> >  >  >> -lXext
> >  >  >> /usr/bin/ld: swscale.o: relocation R_X86_64_32S against `a local symbol'
> >  >  >> can not be used when making a shared object; recompile with -fPIC
> >  >  >> swscale.o: could not read symbols: Bad value
> >  >  >> collect2: ld returned 1 exit status
> >  >  >> make[1]: *** [libswscale.so.0] Error 1
> >  >  >> make[1]: Leaving directory `/tmp/ffmpeg/libswscale'
> >  >  >> make: *** [lib] Error 2
> >  >  >> [gert at apollo ffmpeg]$
> >  >  >
> >  >  > The attached patch fixes 64-bit but breaks any system with an
> >  >  > EXTERN_PREFIX.
> >  >  > Suggestions?
> >  >
> >  >  Well figure out the proper syntax for all the systems and do whatever
> >  >  is needed so that it ends in there.
> >  >
> >  >  [...]
> >
> >  This patch generates the right asm by making a new LOCAL_MANGLE().
> >
> >  I tested it on 64-bit, but it turns out fast_bilinear crashes there
> >  whether or not the patch is applied, unless you run it under valgrind.
> >  Don't have time to debug it.
> 
> Or maybe I do; it's just an executable stack issue. configure didn't
> check for mmap, so this fixes it on any system with non-executable
> stacks and mmap.

Patch applied, we did sport HAVE_SYS_MMAP_H in libswscale without a
proper check in configure.

However, I assume this does not take care of the linking issue, does it?

Diego