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

[Reimar Döffinger]

On Wed, Mar 19, 2008 at 01:39:16PM +0800, Zuxy Meng wrote:
> 2008/3/19, Alexander Strange <astrange at ithinksw.com>:
> > 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.
> 
> Because we're using self-modifying code but don't follow Intel/AMD's
> suggestions?

I fixed that a long time ago, even for Windows, just that I never
applied the code for Windows since nobody cared to even test it.
It can be found on the MPlayer-dev list if someone wants support for non-executable
stack on Windows...