[Ffmpeg-devel] Compilation broken in last 24 hours due to 3DNow changes

Guillaume POIRIER poirierg
Mon May 15 07:40:45 CEST 2006


On 5/15/06, Diamond Software <diamondsw at mac.com> wrote:
> The CVS commit last night changing the main configure file and the
> libavcodec file to use -m3dnow instead of -march=athlon has broken
> compilation on my system (MacBook Pro with Mac OS X 10.4.6, on an
> Intel Core Duo). The error is:
> cc -O3 -g -Wall -Wno-switch  -DHAVE_LRINTF -I/Users/jochs/Documents/
> Development/Tivo/TivoServer/ffmpeg/faac/include/ -I/Users/jochs/
> Documents/Development/Tivo/TivoServer/ffmpeg/faad/include/ -I/Users/
> jochs/Documents/Development/Tivo/TivoServer/ffmpeg/lame-3.96.1/
> include/ -I/Users/jochs/Documents/Development/Tivo/TivoServer/ffmpeg/
> xvidcore-1.1.0/src/ -no-cpp-precomp -pipe -fomit-frame-pointer -
> force_cpusubtype_ALL -Wno-sign-compare -mdynamic-no-pic -
> DHAVE_AV_CONFIG_H -I.. -I/Users/jochs/Documents/Development/Tivo/
> TivoServer/ffmpeg/libavutil -D_FILE_OFFSET_BITS=64 -
> D_LARGEFILE_SOURCE -D_GNU_SOURCE  -m3dnow  -c -o i386/fft_3dn2.o i386/
> fft_3dn2.c
> i386/fft_3dn2.c: In function 'ff_fft_calc_3dn2':
> i386/fft_3dn2.c:66: warning: implicit declaration of function
> '_m_pswapd'
> i386/fft_3dn2.c:66: error: incompatible types in assignment
> i386/fft_3dn2.c:105: error: incompatible types in assignment
> i386/fft_3dn2.c:106: error: incompatible types in assignment
> i386/fft_3dn2.c:112: warning: implicit declaration of function
> '_m_pfpnacc'
> i386/fft_3dn2.c:112: error: incompatible types in assignment
> i386/fft_3dn2.c:113: error: incompatible types in assignment
> make[1]: *** [i386/fft_3dn2.o] Error 1
> make: *** [lib] Error 2
> The first strange thing is why 3DNow code is being used at all, since
> I don't have an AMD chip. Seems to me something must be wrong the the
> configure check, as it thinks 3DNow should be enabled:
> 3DNow! Builtins  yes
> Here's my ugly-as-hell configure statement:
> ./configure --enable-static --disable-shared --enable-memalign-hack --
> enable-gpl --disable-vhook --disable-ffplay --disable-ffserver --
> enable-pthreads --enable-a52 --enable-amr_nb --enable-amr_wb --enable-
> faac --enable-faad --enable-mp3lame --enable-xvid \
> --extra-cflags="-DHAVE_LRINTF -I`pwd`/faac/include/ -I`pwd`/faad/
> include/ -I`pwd`/lame-3.96.1/include/ -I`pwd`/xvidcore-1.1.0/src/" --
> extra-ldflags="-L`pwd`/faac/libfaac/.libs/ -L`pwd`/faad/
> libfaad/.libs/ -L`pwd`/lame-3.96.1/libmp3lame/.libs/ -L`pwd`/
> xvidcore-1.1.0/build/generic/\=build/"
> The second strange thing is why that specific change would cause
> compilation to break; one would think that everything would be the
> same since the checks were the same in both the configure file and
> the Makefile.

Exactly, though a quick glance at the configure code shows that the
test isn't right:
It only checks the existence of mm3dnow.h, but doesn't attempt to
compile anything using 3dnow intrinsincs.

The correct fix is IMHO to import part of what is in MPlayer's
configure, i.e. test if compilation works with _m_femms and with

> I can verify that reverting to the old Makefile and configure file
> allow me to build normally again. I would request that the patch be
> pulled back for further review, especially concerning how 3DNow
> capability is being detected.

Makes sense.

I will try to come up with a fix tonite, unless someone beats me for it.

I am disillusioned enough to know that no man's opinion on any subject
is worth a damn unless backed up with enough genuine information to
make him really know what he's talking about.

-- H. P. Lovecraft (about the flamewars on FFmpeg and MPlayer-dev mailing lists)

More information about the ffmpeg-devel mailing list