compilation troubles on MacIntel

[stranche@…]

this is a new bug report made to differ from bug #514 wich evolved in a win32
DLL support on MacIntel thread.

I'll report here the troubles I found while trying to compile SVN (retrieved on
august 06, 10pm paris time).

when compiled with
./configure --disable-win32
make

gives this

cc -I../libvo -I../../libvo -fno-PIC -O4 -march=pentium-m -mtune=pentium-m -pipe
-ffast-math -fomit-frame-pointer -mdynamic-no-pic -falign-loops=16 -DSYS_DARWIN
-DCONFIG_DARWIN -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/X11R6/include
-I/usr/src/DVB/ost/include -I/usr/src/DVB/include -I/usr/include/dxr2
-I/usr/local/include/cdda -I/usr/X11R6/include -I/usr/X11R6/include/freetype2
-DHAVE_AV_CONFIG_H -I.. -I../libavutil -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE -c -o i386/fdct_mmx.o i386/fdct_mmx.c
{standard input}:unknown:file contains unmatched .macro and .endmacro for:
FDCT_ROW_SSE2_H1it
make[1]: * [i386/fdct_mmx.o] Error 1
make: * [libavcodec/libavcodec.a] Error 2

when compiled with
./configure --disable-win32 --disable-mmx --disable-mmxext --disable-3dnow
--disable-3dnowext --disable-sse --disable-sse2
make

(first strangeness, you can see those in the configure :
Checking for kernel support of mmx ... yes
Checking for kernel support of mmxext ... yes
Checking for kernel support of sse ... yes
Checking for kernel support of sse2 ... yes

Optimizing for: pentium-m mmx mmxext sse sse2 mtrr

Should logically not appear since we set the disable options, this works with
MPlayer 1.0pre8 as shown in bug #514)

cc -c -I../libvo -I../../libvo -fno-PIC -O4 -march=pentium-m -mtune=pentium-m
-pipe -ffast-math -fomit-frame-pointer -mdynamic-no-pic -falign-loops=16
-DSYS_DARWIN -DCONFIG_DARWIN -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/X11R6/include -I/usr/src/DVB/ost/include -I/usr/src/DVB/include
-I/usr/include/dxr2 -I/usr/local/include/cdda -I/usr/X11R6/include
-I/usr/X11R6/include/freetype2 -I. -I.. -o getch2.o getch2.c
ar r libosdep.a shmem.o strsep.o strl.o vsscanf.o scandir.o gettimeofday.o
fseeko.o swab.o setenv.o timer-darwin.o getch2.o
ar: creating archive libosdep.a
ranlib: file: libosdep.a(strsep.o) has no symbols
ranlib: file: libosdep.a(strl.o) has no symbols
ranlib: file: libosdep.a(vsscanf.o) has no symbols
ranlib: file: libosdep.a(scandir.o) has no symbols
ranlib: file: libosdep.a(gettimeofday.o) has no symbols
ranlib: file: libosdep.a(fseeko.o) has no symbols
ranlib: file: libosdep.a(swab.o) has no symbols
ranlib: file: libosdep.a(setenv.o) has no symbols
ranlib libosdep.a
ranlib: file: libosdep.a(strsep.o) has no symbols
ranlib: file: libosdep.a(strl.o) has no symbols
ranlib: file: libosdep.a(vsscanf.o) has no symbols
ranlib: file: libosdep.a(scandir.o) has no symbols
ranlib: file: libosdep.a(gettimeofday.o) has no symbols
ranlib: file: libosdep.a(fseeko.o) has no symbols
ranlib: file: libosdep.a(swab.o) has no symbols
ranlib: file: libosdep.a(setenv.o) has no symbols
make -C libswscale LIBPREF=lib LIBSUF=.a
cc -I../libvo -I../../libvo -fno-PIC -O4 -march=pentium-m -mtune=pentium-m -pipe
-ffast-math -fomit-frame-pointer -mdynamic-no-pic -falign-loops=16 -DSYS_DARWIN
-DCONFIG_DARWIN -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/X11R6/include
-I/usr/src/DVB/ost/include -I/usr/src/DVB/include -I/usr/include/dxr2
-I/usr/local/include/cdda -I/usr/X11R6/include -I/usr/X11R6/include/freetype2
-I.. -I.. -I../libavutil -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o swscale.o swscale.c
In file included from swscale.c:796:
swscale_template.c: In function 'hyscale_C':
swscale_template.c:2469: warning: pointer targets in passing argument 1 of
'hScale_C' differ in signedness
swscale_template.c: In function 'hcscale_C':
swscale_template.c:2653: warning: pointer targets in passing argument 1 of
'hScale_C' differ in signedness
swscale_template.c:2654: warning: pointer targets in passing argument 1 of
'hScale_C' differ in signedness
swscale_template.c: In function 'swScale_C':
swscale_template.c:2926: warning: pointer targets in passing argument 1 of
'hyscale_C' differ in signedness
swscale_template.c:2943: warning: pointer targets in passing argument 1 of
'hcscale_C' differ in signedness
swscale_template.c:2968: warning: pointer targets in passing argument 1 of
'hyscale_C' differ in signedness
swscale_template.c:2984: warning: pointer targets in passing argument 1 of
'hcscale_C' differ in signedness
swscale_template.c:3071: warning: pointer targets in passing argument 2 of
'yuv2packed1_C' differ in signedness
swscale_template.c:3071: warning: pointer targets in passing argument 3 of
'yuv2packed1_C' differ in signedness
swscale_template.c:3071: warning: pointer targets in passing argument 4 of
'yuv2packed1_C' differ in signedness
swscale_template.c:3082: warning: pointer targets in passing argument 2 of
'yuv2packed2_C' differ in signedness
swscale_template.c:3082: warning: pointer targets in passing argument 3 of
'yuv2packed2_C' differ in signedness
swscale_template.c:3082: warning: pointer targets in passing argument 4 of
'yuv2packed2_C' differ in signedness
swscale_template.c:3082: warning: pointer targets in passing argument 5 of
'yuv2packed2_C' differ in signedness
cc -I../libvo -I../../libvo -fno-PIC -O4 -march=pentium-m -mtune=pentium-m -pipe
-ffast-math -fomit-frame-pointer -mdynamic-no-pic -falign-loops=16 -DSYS_DARWIN
-DCONFIG_DARWIN -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/X11R6/include
-I/usr/src/DVB/ost/include -I/usr/src/DVB/include -I/usr/include/dxr2
-I/usr/local/include/cdda -I/usr/X11R6/include -I/usr/X11R6/include/freetype2
-I.. -I.. -I../libavutil -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o rgb2rgb.o rgb2rgb.c
In file included from rgb2rgb.c:170:
rgb2rgb_template.c: In function 'rgb15to24_MMX':
rgb2rgb_template.c:993: error: 'mmx_null' undeclared (first use in this function)
rgb2rgb_template.c:993: error: (Each undeclared identifier is reported only once
rgb2rgb_template.c:993: error: for each function it appears in.)
rgb2rgb_template.c:933: error: memory input 5 is not directly addressable
rgb2rgb_template.c: In function 'rgb16to24_MMX':
rgb2rgb_template.c:1134: error: 'mmx_null' undeclared (first use in this function)
rgb2rgb_template.c:1075: error: memory input 5 is not directly addressable
In file included from rgb2rgb.c:179:
rgb2rgb_template.c: In function 'rgb15to24_MMX2':
rgb2rgb_template.c:993: error: 'mmx_null' undeclared (first use in this function)
rgb2rgb_template.c:933: error: memory input 5 is not directly addressable
rgb2rgb_template.c: In function 'rgb16to24_MMX2':
rgb2rgb_template.c:1134: error: 'mmx_null' undeclared (first use in this function)
rgb2rgb_template.c:1075: error: memory input 5 is not directly addressable
In file included from rgb2rgb.c:188:
rgb2rgb_template.c: In function 'rgb15to24_3DNOW':
rgb2rgb_template.c:993: error: 'mmx_null' undeclared (first use in this function)
rgb2rgb_template.c:933: error: memory input 5 is not directly addressable
rgb2rgb_template.c: In function 'rgb16to24_3DNOW':
rgb2rgb_template.c:1134: error: 'mmx_null' undeclared (first use in this function)
rgb2rgb_template.c:1075: error: memory input 5 is not directly addressable
make[1]: * [rgb2rgb.o] Error 1
make: * [libswscale/libswscale.a] Error 2

It seems that the various --disable commands are ignored (or something still
needs MMX code further during compile)

[diego@…]

Fixed.

[stranche@…]

Does not compile right again on MacIntel hardware.

SVN retrieved 5 october 2006 at 10am Paris time.

I'll attach here the log files corresponding to configure and make with :

./configure --disable-win32 (win32 libs depends on bug #514)
./configure --disable-win32 --disable-mmx
./configure --disable-win32 --disable-mmx --disable-sse

[stranche@…]

log of ./configure --disable-win32

[stranche@…]

log of make with ./configure --disable-win32

[stranche@…]

log of ./configure --disable-win32 --disable-mmx

[stranche@…]

log of make with ./configure --disable-win32 --disable-mmx

[stranche@…]

log of ./configure --disable-win32 --disable-mmx --disable-sse

[stranche@…]

log of make with ./configure --disable-win32 --disable-mmx --disable-sse

[reimar]

You need --disable-mp3lib
This is unlikely to get fixed anytime soon.

[stranche@…]

(In reply to comment #9)

You need --disable-mp3lib

Thanks for the hint Reimar, when disabling the mp3lib part it does compiles OK,
however the sound of most of my files (using divx video + MP3 audio) becomes
completely scrambled.

You can hear that the sound is playing, but is completely covered by huge and
nasty cracking sounds and get tons of those on the console :

[mp3 @ 0x626860]header missing skiping one byte
[mp3 @ 0x626860]header missing skiping one byte
[mp3 @ 0x626860]header missing skiping one byte
[mp3 @ 0x626860]header missing skiping one byte
[mp3 @ 0x626860]header missing skiping one byte
[mp3 @ 0x626860]header missing skiping one byte
[mp3 @ 0x626860]header missing skiping one byte
[mp3 @ 0x626860]incorrect frame size
overread, skip -7 enddists: -2 -2
overread, skip -5 enddists: -4 -4
overread, skip -5 enddists: -2 -2
overread, skip -7 enddists: -3 -3

those troubles needs some love by someone good at programming...

[stranche@…]

(In reply to comment #10)
to complete previous comment.

the cracking thing does not happen with all the files, so there's hope.

My guess it that this trouble is due to the differences in the MP3 format used
in the file : different bitrates, VBR, and so on...

[diego@…]

(In reply to comment #10)

(In reply to comment #9)

You need --disable-mp3lib

Thanks for the hint Reimar, when disabling the mp3lib part it does compiles OK,
however the sound of most of my files (using divx video + MP3 audio) becomes
completely scrambled.

We need a sample to be able to reproduce and fix this.

[stranche@…]

avi sample with cracking sound

[stranche@…]

another avi sample with cracking sound (slightly different)

[stranche@…]

avi sample playing OK (for comparition purpose)

[stranche@…]

another avi sample playing OK (for comparition purpose)

[diego@…]

Use -demuxer lavf and the files will play fine.

I'm marking the bug as fixed again. Separate issues should go in another bug.

[stranche@…]

(In reply to comment #17)

Use -demuxer lavf and the files will play fine.

I'm marking the bug as fixed again. Separate issues should go in another bug.

When I encountered this bug I couldn't know it was completely unrelated to the
original problem of non-compilation, it seemed to me that the compile didn't
produce a working mplayer executable since sound was broken.

Now, the question is should a different bug be opened or are you already on
something to fix this ?

[reimar]

The libavcodec mp3 decoder does not work with AVI files anymore (unless using
-demuxer lavf). If you add support for libmad it should work with that though.

[stranche@…]

(In reply to comment #19)

The libavcodec mp3 decoder does not work with AVI files anymore (unless using
-demuxer lavf). If you add support for libmad it should work with that though.

Is such particularities good for the project that is MPlayer ?
I mean :
-compiling Mplayer for MacIntel needs to use --disable-win32 (since it's a
usable x86 archi it will try to use it) and --disable-mp3lib.
-playing video files with the obtained executable needs the -demuxer=lavf option
to play fine (or include it in ~/.mplayer/config.

Doesn't all those little things you have to be aware of to avoid bad behaviour
just turns MPlayer opaque ?

For me it should detect on its own all of these at building time to make a
working executable out of the box.

[diego@…]

(In reply to comment #20)

(In reply to comment #19)

The libavcodec mp3 decoder does not work with AVI files anymore (unless using
-demuxer lavf). If you add support for libmad it should work with that though.

Is such particularities good for the project that is MPlayer ?
I mean :
-compiling Mplayer for MacIntel needs to use --disable-win32 (since it's a
usable x86 archi it will try to use it) and --disable-mp3lib.
-playing video files with the obtained executable needs the -demuxer=lavf option
to play fine (or include it in ~/.mplayer/config.

Doesn't all those little things you have to be aware of to avoid bad behaviour
just turns MPlayer opaque ?

For me it should detect on its own all of these at building time to make a
working executable out of the box.

As always: Patches welcome.

[reimar]

Even if it sounds a bit rude, Diego is completely right.
The MP3 problems is fully and exclusively caused by Apple's toolchain, as are
many of the win32 loader problems.
Which means to reproduce and thus to efficiently work on it you have to have an
Intel Mac. Which I (and many/most/all?) developers do not.
In the case of the loader problems the necessary patches are available but
nobody seems to be persistent enough to do final cleanups and try to push them
in part by part (which, admittedly, for some parts will be really hard).

[stranche@…]

(In reply to comment #22)

Even if it sounds a bit rude, Diego is completely right.

No problem, no offense taken.

The MP3 problems is fully and exclusively caused by Apple's toolchain, as are
many of the win32 loader problems.
Which means to reproduce and thus to efficiently work on it you have to have an
Intel Mac. Which I (and many/most/all?) developers do not.

That's one of the problems, my knowledge on the programming field is far from
enough to be able to fix bugs I can discover (alas, o god, alas !!).
However if you need someone to test some patchs I would be more than happy to do so.

In the case of the loader problems the necessary patches are available but
nobody seems to be persistent enough to do final cleanups and try to push them
in part by part (which, admittedly, for some parts will be really hard).

the friend that made a working win32 DLL loader (this one cost me a restaurant
meal :p) is now working in Japan, I talked with him about working on the newest
MPlayer code wich is on the SVN and compiles now clean on OSX (with
--disable-mp3lib however) to adapt the existing patch against 1.0pre8. But right
now he his short in time so it may be not happen during the next weeks or more.