MPlayer does not compile right on Apple Intel based hardware

[stranche@…]

on Macbook Pro with OSX 10.4 Intel + Xcode

the WINE part crashes when compiling (after integration the DLL on
/usr/local/lib/codecs/ and detection at ./configure )

here is the error log of the moment if fails :

cc -I. -I.. -I../libvo -I../../libvo -I/usr/X11R6/include -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 -U_FILE_OFFSET_BITS -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -DMPLAYER -DWINE -c pe_image.c
In file included from wine/winnt.h:1043,

from wine/winbase.h:5,
from pe_image.c:56:

wine/poppack.h:5: error: too many #pragma options align=reset
In file included from wine/winnt.h:1494,

from wine/winbase.h:5,
from pe_image.c:56:

wine/poppack.h:5: error: too many #pragma options align=reset
In file included from wine/winnt.h:2170,

from wine/winbase.h:5,
from pe_image.c:56:

wine/poppack.h:5: error: too many #pragma options align=reset
In file included from wine/winnt.h:2667,

from wine/winbase.h:5,
from pe_image.c:56:

wine/poppack.h:5: error: too many #pragma options align=reset
In file included from wine/winbase.h:1083,

from pe_image.c:56:

wine/poppack.h:5: error: too many #pragma options align=reset
In file included from wine/module.h:76,

from pe_image.c:60:

wine/poppack.h:5: error: too many #pragma options align=reset
In file included from pe_image.c:61:
wine/debugtools.h:67: warning: useless type name in empty declaration
pe_image.c: In function 'fixup_imports':
pe_image.c:315: warning: pointer targets in passing argument 2 of
'LookupExternalByName' differ in signedness
pe_image.c:336: warning: pointer targets in passing argument 2 of
'LookupExternalByName' differ in signedness
make[1]: * [pe_image.o] Error 1
make: * [loader/libloader.a] Error 2

tested on 1.0pre8 and today's SVN

[stranche@…]

compile also fails if done with ./configure --disable-win32

here is the output :

cc -I../libvo -I../../libvo -I/usr/X11R6/include -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
-DHAVE_AV_CONFIG_H -I..
-I/Users/stranche/Documents/devel/MPlayer-1.0pre8/libavutil
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_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
corvette:~/Documents/devel/MPlayer-1.0pre8 stranche$ make
make -C libavcodec LIBPREF=lib LIBSUF=.a
cc -I../libvo -I../../libvo -I/usr/X11R6/include -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
-DHAVE_AV_CONFIG_H -I..
-I/Users/stranche/Documents/devel/MPlayer-1.0pre8/libavutil
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_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

[stranche@…]

output generated from the ./configure command

[stranche@…]

infos from an Intel macbook Pro 2.13GHz

[stranche@…]

In an atempt to go further :

using a bogus value to loader/wine/poppack.h:5 like #pragma pack(4) allows
to pass the error but you fail after with this :

make -C loader
cc -c -o wrapper.o wrapper.S
wrapper.S:1:Expected comma after segment-name
wrapper.S:1:Rest of line ignored. 1st junk character valued 46 (.).
wrapper.S:10:Unknown pseudo-op: .global
wrapper.S:10:Rest of line ignored. 1st junk character valued 119 (w).
wrapper.S:14:Expected comma after segment-name
wrapper.S:14:Rest of line ignored. 1st junk character valued 46 (.).
wrapper.S:15:Unknown pseudo-op: .type
wrapper.S:15:Rest of line ignored. 1st junk character valued 110 (n).
wrapper.S:16:Unknown pseudo-op: .balign
wrapper.S:16:Rest of line ignored. 1st junk character valued 49 (1).
wrapper.S:20:Unknown pseudo-op: .type
wrapper.S:20:Rest of line ignored. 1st junk character valued 119 (w).
wrapper.S:21:Unknown pseudo-op: .balign
wrapper.S:21:Rest of line ignored. 1st junk character valued 49 (1).
wrapper.S:54:Unknown pseudo-op: .balign
wrapper.S:54:Rest of line ignored. 1st junk character valued 49 (1).
make[1]: * [wrapper.o] Error 1
make: * [loader/libloader.a] Error 2

[stranche@…]

infos from an Intel macbook 1.8GHz (not the pro one)

[stranche@…]

log of the 'make -i' command (to show ALL errors)

[stranche@…]

this is a log of the output done by 'make -i' command.

it shows in one time all the errors happening during compilation.

[stranche@…]

output from ./configure on a PPC system

[stranche@…]

this is the output generated by the ./configure command on a Apple PPC system
with the same OSX version (10.4.6) and the same Xcode version (2.3).

Only the archi type is different.

Compiles fine on PPC.

[stranche@…]

with some friends we found something fun about the pragma thing :

create and compile a .c file with this content :

#pragma pack()
int main() { }

compiles fine and gives you a a.out file on :
-Linux 32bit with GCC 4.0.3
-Linux 32bit with GCC 4.1.0
-Linux 64bit with GCC 3.4.5
-FreeBSD 32bit with GCC 4.1.0

fails with this error
toto.c:1: error: too many #pragma options align=reset
on the following :
-OSX 10.4.6 PPC with Xcode 2.3
-OSX 10.4.6 Intel with Xcode 2.3

[stranche@…]

Our experiments showed us the following:

it compiles OK with the following options set

./configure --disable-win32 --disable-dshow --disable-mmx --disable-mmxext
--disable-3dnow --disable-3dnowext --disable-sse --disable-sse2 --disable-fastmemcpy

it seems the GCC into Xcode on Intel architecture doesn't like the asm present
in some parts like win32 and mp3lib

[stranche@…]

(In reply to comment #9)
To be complete, here is the report done by my friend Darksoul that experimented
quite a bit :

Code bits that must be disabled for compilation to work : every code bit that
depends on x86 raw ASM code. Namely, "mp3lib", "loader/win32", "loader/dshow".
This is mainly because asm code made for PC i386 is not compatible with Mac OS X
i386, as error messages suggest.

Perhaps it would be wise to detect Darwin systems, and avoid the use of PC/i386
related code, and direct it to MAC/i386 code?

​http://developer.apple.com/documentation/DeveloperTools/Reference/Assembler/Assembler.pdf

[diego@…]

Nicolas, Mac OS X is your territory, plus you have an Intel Mac ...

[stranche@…]

(In reply to comment #10)

Another bit from Darksoul :

loader/wrapper.S makes use of both ".global" and ".globl" statements (which act,
according to the GNU Assembler Reference, the same way.), and it seems that GCC
on Darwin systems doesn't support ".global"

=> Replace ".global" statements with ".globl"

[stephane.lapie@…]

(In reply to comment #12)

(In reply to comment #10)

Another bit from Darksoul :

loader/wrapper.S makes use of both ".global" and ".globl" statements (which act,
according to the GNU Assembler Reference, the same way.), and it seems that GCC
on Darwin systems doesn't support ".global"

=> Replace ".global" statements with ".globl"

DarkSoul here.

I'm currently fiddling a little more with loader/wrapper.S and with both
references for MacOS X Assembly and GNU Assembler.

Darwin GCC seems to be whining about .section directives too :
wrapper.S: 1:.section .data
wrapper.S:15:.section .text

which can be replaced with ".data" and ".text"

Then there is the matter of the ".balign" directives. I have looked up a bit on
both references again, and found it might be worth a try to replace :
.balign 16, 0x90
with :
.p2align 4, 0x90

I also saw ".type" directives, but I don't really know what to do with them, so
for the time being I commented them after reading that this directive was not
used by the GNU Assembler anyway.

I also modified the stubs.s file who was opposing some resistance due to a
.balign and a .string directive (substitued them with an appropriate .p2align
and .ascii directives).

Still, I didn't get much luck re-enabling win32 and dshow with that fix, because
I still would get link errors.

/usr/bin/ld: Undefined symbols:
_report_entry
_report_ret
_wrapper
_wrapper_target
_exp_EH_prolog

This is because the symbols referenced in the .s files didn't have the _
prefixed to them. By adding them, I achieved a successful build on stephane t's
Macbook. As I was using a remote access, I couldn't actually test the resulting
binary.

My modified files are available here :
​http://www.darkbsd.org/~darksoul/wrapper.S
​http://www.darkbsd.org/~darksoul/stubs.s

These allow to achieve a successful build on a Macbook with the following options :
./configure --disable-mmx --disable-mmxext
--disable-3dnow --disable-3dnowext --disable-sse --disable-sse2 --disable-fastmemcpy

I am currently expermenting with them on a regular i386/FreeBSD system. More
details later on. :)

[stephane.lapie@…]

(In reply to comment #13)

(In reply to comment #12)

(In reply to comment #10)

Another bit from Darksoul :

loader/wrapper.S makes use of both ".global" and ".globl" statements (which act,
according to the GNU Assembler Reference, the same way.), and it seems that GCC
on Darwin systems doesn't support ".global"

=> Replace ".global" statements with ".globl"

DarkSoul here.

I'm currently fiddling a little more with loader/wrapper.S and with both
references for MacOS X Assembly and GNU Assembler.

Darwin GCC seems to be whining about .section directives too :
wrapper.S: 1:.section .data
wrapper.S:15:.section .text

which can be replaced with ".data" and ".text"

Then there is the matter of the ".balign" directives. I have looked up a bit on
both references again, and found it might be worth a try to replace :
.balign 16, 0x90
with :
.p2align 4, 0x90

I also saw ".type" directives, but I don't really know what to do with them, so
for the time being I commented them after reading that this directive was not
used by the GNU Assembler anyway.

I also modified the stubs.s file who was opposing some resistance due to a
.balign and a .string directive (substitued them with an appropriate .p2align
and .ascii directives).

Still, I didn't get much luck re-enabling win32 and dshow with that fix, because
I still would get link errors.

/usr/bin/ld: Undefined symbols:
_report_entry
_report_ret
_wrapper
_wrapper_target
_exp_EH_prolog

This is because the symbols referenced in the .s files didn't have the _
prefixed to them. By adding them, I achieved a successful build on stephane t's
Macbook. As I was using a remote access, I couldn't actually test the resulting
binary.

My modified files are available here :
​http://www.darkbsd.org/~darksoul/wrapper.S
​http://www.darkbsd.org/~darksoul/stubs.s

These allow to achieve a successful build on a Macbook with the following

options :

./configure --disable-mmx --disable-mmxext
--disable-3dnow --disable-3dnowext --disable-sse --disable-sse2

--disable-fastmemcpy

I am currently expermenting with them on a regular i386/FreeBSD system. More
details later on. :)

Correction on our experiments :

Compile before modifying wrapper.S and stubs.s worked with :
./configure --disable-win32 --disable-dshow --disable-mmx --disable-mmxext
--disable-3dnow --disable-3dnowext --disable-sse --disable-sse2
--disable-fastmemcpy --disable-mp3lib

Compile after modification worked with :
./configure --disable-mmx --disable-mmxext --disable-3dnow --disable-3dnowext
--disable-sse --disable-sse2 --disable-fastmemcpy --disable-mp3lib

Disabling mp3lib is paramount since that lib requires no matter what compiling
of assembly code, and thus is crippled on Macbook.

[stephane.lapie@…]

(In reply to comment #14)

I am currently expermenting with them on a regular i386/FreeBSD system. More
details later on. :)

The modified .s files with mangled symbol names didn't work on FreeBSD, as one
could expect. Perhaps these files should be modified so that a macro similar to
libavcodec's MANGLE() (from libavutil/common.h) can be applied to them.

[stephane.lapie@…]

(In reply to comment #15)

(In reply to comment #14)

I am currently expermenting with them on a regular i386/FreeBSD system. More
details later on. :)

The modified .s files with mangled symbol names didn't work on FreeBSD, as one
could expect. Perhaps these files should be modified so that a macro similar to
libavcodec's MANGLE() (from libavutil/common.h) can be applied to them.

Even though modified code did not break anything on my i386/FreeBSD system, it
still doesn't work on Macbook with Darwin.

Using mencoder on a WMV9 file (yes, I do have the right DLL in the right place)
gives this error :

Opening video decoder: [dmo] DMO video codecs
ERROR: Couldn't allocate memory for fs segment: Operation not supported by device
Win32 LoadLibrary failed to load: wmv9dmod.dll,
/usr/local/lib/codecs/wmv9dmod.dll, /usr/lib/win32/wmv9dmod.dll,
/usr/local/lib/win32/wmv9dmod.dll
IMediaObject ERROR: 0x415068 could not open DMO DLL (0x0 : 0)
Failed to create DMO filter
ERROR: Could not open required DirectShow codec wmv9dmod.dll.
You need to upgrade/install the binary codecs package.
Go to ​http://www.mplayerhq.hu/dload.html
VDecoder init failed :(

Opening video decoder: [dmo] DMO video codecs
ERROR: Couldn't allocate memory for fs segment: Operation not supported by device
Win32 LoadLibrary failed to load: wmvdmod.dll,
/usr/local/lib/codecs/wmvdmod.dll, /usr/lib/win32/wmvdmod.dll,
/usr/local/lib/win32/wmvdmod.dll
IMediaObject ERROR: 0x415068 could not open DMO DLL (0x0 : 0)
Failed to create DMO filter
ERROR: Could not open required DirectShow codec wmvdmod.dll.
You need to upgrade/install the binary codecs package.
Go to ​http://www.mplayerhq.hu/dload.html
VDecoder init failed :(

So close, and yet so far :/

[stephane.lapie@…]

About the following error message :

ERROR: Couldn't allocate memory for fs segment: Operation not supported by device

Investigation on the loader code reveals that ldt_keeper.c uses legacy way of
generating it's memory segment (feeding from a fd open on /dev/zero).

Diff for loader/ldt_keeper.c included. Basically, I've replaced the mmap()
feeding from the fd of /dev/zero to a mmap(MAP_ANON), in the event CONFIG_DARWIN
is defined. This seems to work. Tested on i386/FreeBSD with success, doesn't
seem to break, even though MAP_ANON flag might not be available on some platforms.

I've recompiled MPlayer with debug options and tweaked the loader to enable
traces, obtaining the error log below, upon reading WMV9 files :

FindModule: Module wmv9dmod.dll request
Trying native dll 'wmv9dmod.dll'
Failed to load module 'wmv9dmod.dll'; error=0x00000002,
Trying native dll '/usr/local/lib/codecs/wmv9dmod.dll'
Dump of segment table

Name VSz Vaddr SzRaw Fileadr *Reloc *Lineum #Reloc #Linum Char
.text: a454d 00001000 000a4600 00000400 00000000 00000000 0000 0000 60000020
.data: 26bfc 000a6000 0001aa00 000a4a00 00000000 00000000 0000 0000 c0000040
.rsrc: 03d0 000cd000 00000400 000bf400 00000000 00000000 0000 0000 40000040

.reloc: 3c7e 000ce000 00003e00 000bf800 00000000 00000000 0000 0000 42000040

We need to perform base relocations for /usr/local/lib/codecs/wmv9dmod.dll
FATAL: Couldn't load module /usr/local/lib/codecs/wmv9dmod.dll (out of memory,
859648 needed)!
Failed to load module '/usr/local/lib/codecs/wmv9dmod.dll'; error=0x0000000e,
Trying native dll '/usr/lib/win32/wmv9dmod.dll'
Failed to load module '/usr/lib/win32/wmv9dmod.dll'; error=0x00000002,
Trying native dll '/usr/local/lib/win32/wmv9dmod.dll'
Failed to load module '/usr/local/lib/win32/wmv9dmod.dll'; error=0x00000002,
Win32 LoadLibrary failed to load: wmv9dmod.dll,
/usr/local/lib/codecs/wmv9dmod.dll, /usr/lib/win32/wmv9dmod.dll,
/usr/local/lib/win32/wmv9dmod.dll
IMediaObject ERROR: 0x3e99e4 could not open DMO DLL (0x0 : 0)
Failed to create DMO filter
ERROR: Could not open required DirectShow codec wmv9dmod.dll.
You need to upgrade/install the binary codecs package.
Go to ​http://www.mplayerhq.hu/dload.html
VDecoder init failed :(

Opening video decoder: [dmo] DMO video codecs
FindModule: Module wmvdmod.dll request
Trying native dll 'wmvdmod.dll'
Failed to load module 'wmvdmod.dll'; error=0x00000002,
Trying native dll '/usr/local/lib/codecs/wmvdmod.dll'
Dump of segment table

Name VSz Vaddr SzRaw Fileadr *Reloc *Lineum #Reloc #Linum Char
.text: a466d 00001000 000a4800 00000400 00000000 00000000 0000 0000 60000020
.data: 26c2c 000a6000 0001aa00 000a4c00 00000000 00000000 0000 0000 c0000040
.rsrc: 03d0 000cd000 00000400 000bf600 00000000 00000000 0000 0000 40000040

.reloc: 3c9a 000ce000 00003e00 000bfa00 00000000 00000000 0000 0000 42000040

We need to perform base relocations for /usr/local/lib/codecs/wmvdmod.dll
FATAL: Couldn't load module /usr/local/lib/codecs/wmvdmod.dll (out of memory,
859648 needed)!
Failed to load module '/usr/local/lib/codecs/wmvdmod.dll'; error=0x0000000e,
Trying native dll '/usr/lib/win32/wmvdmod.dll'
Failed to load module '/usr/lib/win32/wmvdmod.dll'; error=0x00000002,
Trying native dll '/usr/local/lib/win32/wmvdmod.dll'
Failed to load module '/usr/local/lib/win32/wmvdmod.dll'; error=0x00000002,
Win32 LoadLibrary failed to load: wmvdmod.dll,
/usr/local/lib/codecs/wmvdmod.dll, /usr/lib/win32/wmvdmod.dll,
/usr/local/lib/win32/wmvdmod.dll
IMediaObject ERROR: 0x3e99e4 could not open DMO DLL (0x0 : 0)
Failed to create DMO filter
ERROR: Could not open required DirectShow codec wmvdmod.dll.
You need to upgrade/install the binary codecs package.
Go to ​http://www.mplayerhq.hu/dload.html
VDecoder init failed :(
Cannot find codec matching selected -vo and video format 0x33564D57.
Read DOCS/HTML/en/codecs.html!

Currently investigating on why VirtualAlloc (in pe_image.c:597) returns a NULL
pointer.

[stephane.lapie@…]

This diff makes ldt_keeper's mmap() call behave properly, while keeping compatibility with other configurations.

[stephane.lapie@…]

Patch file for loader/ext.c. Replaces mmap() calls feeding on /dev/zero with mmap(MAP_ANON) calls for CONFIG_DARWIN case.

[stephane.lapie@…]

I patched loader/ext.c's VirtualAlloc function, finding again cases of mmap()
calls working the same way as above (feeding from a fd open on /dev/zero,
instead of using MAP_ANON), and ran the resulting executable. It seems to load
the DLL all right, but executing its code raises a SIGILL :( Help. Does this
mean that Win32 DLLs really are impossible to run on Macbooks ?

Here is the detailed execution trace :
Opening video decoder: [dmo] DMO video codecs
FindModule: Module wmv9dmod.dll request
Trying native dll 'wmv9dmod.dll'
Failed to load module 'wmv9dmod.dll'; error=0x00000002,
Trying native dll '/usr/local/lib/codecs/wmv9dmod.dll'
Dump of segment table

Name VSz Vaddr SzRaw Fileadr *Reloc *Lineum #Reloc #Linum Char
.text: a454d 00001000 000a4600 00000400 00000000 00000000 0000 0000 60000020

.data: 26bfc 000a6000 0001aa00 000a4a00 00000000 00000000 0000 0000 c0000040

.rsrc: 03d0 000cd000 00000400 000bf400 00000000 00000000 0000 0000 40000040

.reloc: 3c7e 000ce000 00003e00 000bf800 00000000 00000000 0000 0000 42000040

We need to perform base relocations for /usr/local/lib/codecs/wmv9dmod.dll
Load addr is 168ea000 (base 400000), range d1e00
Loading /usr/local/lib/codecs/wmv9dmod.dll at 168ea000, range d1e00
/usr/local/lib/codecs/wmv9dmod.dll: mmaping section .text at 0x168eb000 off 400
size a4600/a454d
/usr/local/lib/codecs/wmv9dmod.dll: mmaping section .data at 0x16990000 off
a4a00 size 1aa00/26bfc
clearing 0x169aaa00 - 0x169ab000
/usr/local/lib/codecs/wmv9dmod.dll: mmaping section .rsrc at 0x169b7000 off
bf400 size 400/3d0
/usr/local/lib/codecs/wmv9dmod.dll: mmaping section .reloc at 0x169b8000 off
bf800 size 3e00/3c7e
78 relocations for page 1000
54 relocations for page 2000
6 relocations for page 3000
20 relocations for page 4000
76 relocations for page 5000
36 relocations for page 6000
42 relocations for page 7000
40 relocations for page 8000
74 relocations for page 9000
18 relocations for page a000
2 relocations for page b000
6 relocations for page c000
6e relocations for page d000
5e relocations for page e000
64 relocations for page f000
8c relocations for page 10000
24 relocations for page 11000
4a relocations for page 12000
5a relocations for page 13000
1e relocations for page 14000
42 relocations for page 15000
58 relocations for page 16000
1c relocations for page 17000
2a relocations for page 18000
2 relocations for page 19000
c relocations for page 1a000
8 relocations for page 1c000
6 relocations for page 1d000
8 relocations for page 1e000
46 relocations for page 1f000
4 relocations for page 20000
a relocations for page 21000
22 relocations for page 22000
26 relocations for page 23000
2c relocations for page 24000
c relocations for page 25000
1e relocations for page 26000
40 relocations for page 28000
12 relocations for page 29000
2 relocations for page 2a000
4 relocations for page 2b000
4 relocations for page 2c000
6 relocations for page 2d000
4 relocations for page 2e000
20 relocations for page 2f000
6 relocations for page 30000
2c relocations for page 35000
72 relocations for page 36000
5c relocations for page 37000
3a relocations for page 38000
2e relocations for page 39000
18 relocations for page 3a000
2a relocations for page 3b000
1a relocations for page 3c000
4 relocations for page 3d000
3c relocations for page 3e000
4 relocations for page 3f000
a relocations for page 40000
12 relocations for page 41000
2 relocations for page 42000
28 relocations for page 43000
2a relocations for page 44000
4 relocations for page 46000
24 relocations for page 47000
2 relocations for page 48000
18 relocations for page 4d000
12 relocations for page 4e000
30 relocations for page 4f000
1a relocations for page 50000
16 relocations for page 51000
14 relocations for page 52000
e relocations for page 53000
1a relocations for page 54000
6 relocations for page 55000
1e relocations for page 56000
4 relocations for page 58000
24 relocations for page 59000
4a relocations for page 5a000
12 relocations for page 5b000
c relocations for page 5c000
2 relocations for page 5e000
10 relocations for page 5f000
2 relocations for page 60000
26 relocations for page 63000
3a relocations for page 64000
46 relocations for page 65000
26 relocations for page 66000
64 relocations for page 67000
70 relocations for page 68000
74 relocations for page 69000
46 relocations for page 6a000
28 relocations for page 6b000
20 relocations for page 6c000
36 relocations for page 6d000
3c relocations for page 6e000
2a relocations for page 6f000
2c relocations for page 70000
2 relocations for page 71000
10 relocations for page 72000
c relocations for page 73000
32 relocations for page 74000
2e relocations for page 75000
16 relocations for page 76000
10 relocations for page 77000
1c relocations for page 78000
40 relocations for page 79000
16 relocations for page 7a000
18 relocations for page 7b000
1a relocations for page 7c000
38 relocations for page 7d000
1c relocations for page 7e000
54 relocations for page 7f000
4 relocations for page 80000
12 relocations for page 81000
4 relocations for page 82000
6 relocations for page 83000
6 relocations for page 85000
24 relocations for page 86000
1a relocations for page 87000
8 relocations for page 88000
2 relocations for page 8a000
2 relocations for page 8b000
a relocations for page 8c000
1e relocations for page 8d000
16 relocations for page 8e000
20 relocations for page 8f000
36 relocations for page 90000
36 relocations for page 91000
18 relocations for page 92000
3c relocations for page 93000
18 relocations for page 94000
20 relocations for page 95000
d2 relocations for page 96000
8c relocations for page 97000
4a relocations for page 98000
60 relocations for page 99000
6e relocations for page 9a000
68 relocations for page 9b000
58 relocations for page 9c000
2 relocations for page 9d000
36 relocations for page 9e000
ec relocations for page 9f000
3e relocations for page a0000
2 relocations for page a1000
6 relocations for page a2000
6e relocations for page a3000
56 relocations for page a4000
7c relocations for page a6000
4 relocations for page a7000
8 relocations for page bc000
4 relocations for page bd000
8 relocations for page bf000
Security directory ignored
Debug directory ignored
Import Address Table directory ignored
*EXPORT DATA*
Module name is DEFFILE.dll, 5 functions, 5 names

Ord RVA Addr Name

1 0000955d 0x168f355d CreateInstance
2 00009217 0x168f3217 DllCanUnloadNow
3 000095c0 0x168f35c0 DllGetClassObject
4 00007890 0x168f1890 DllRegisterServer
5 00007940 0x168f1940 DllUnregisterServer

Dumping imports list
Loading imports for KERNEL32.dll.dll
Microsoft style imports used
Loading imports for msvcrt.dll.dll
Microsoft style imports used
Loading imports for USER32.dll.dll
Microsoft style imports used
Loading imports for GDI32.dll.dll
Microsoft style imports used
Loading imports for ole32.dll.dll
Microsoft style imports used
Loading imports for OLEAUT32.dll.dll
Microsoft style imports used
Loading imports for ADVAPI32.dll.dll
Microsoft style imports used
Loading imports for SHLWAPI.dll.dll
Microsoft style imports used
Loading imports for msdmo.dll.dll
Microsoft style imports used
Loaded module '/usr/local/lib/codecs/wmv9dmod.dll' at 0x168ea000,
(/usr/local/lib/codecs/wmv9dmod.dll,0x0) - START
(/usr/local/lib/codecs/wmv9dmod.dll,PROCESS_ATTACH,0x0) - CALL
(DllMain)
CallTo32(entryproc=0x168f37d4,module=168ea000,type=1,res=0x0)
Entering DllMain(DLL_PROCESS_ATTACH) for /usr/local/lib/codecs/wmv9dmod.dll

MPlayer interrupted by signal 4 in module: init_video_codec

• MPlayer crashed by an 'Illegal Instruction'. It usually happens when you run it on a CPU different than the one it was compiled/optimized for. Verify this!
• MPlayer crashed by bad usage of CPU/FPU/RAM. Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
• MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and won't help unless you provide this information when reporting a possible bug.

[stephane.lapie@…]

loader/wrapper.S patch required for Win32 loader to succesfully build on Macbook

[stephane.lapie@…]

loader/stubs.s patch required for Win32 loader to succesfully build on Macbook

[stephane.lapie@…]

2,3c2,3
< .LC0: .string "Called unk_%s\n"
< .balign 4
---

.LC0: .asciz "Called unk_%s\n"

.p2align 2

17c17
< addl $export_names,%edx
---

addl $_export_names,%edx

20c20
< call printf
---

call _printf

25,26c25,26
< .globl exp_EH_prolog
< exp_EH_prolog:
---

.globl _exp_EH_prolog
_exp_EH_prolog:

[diego@…]

All your patches are useless, they need to be in unified diff format (diff -u).

[stephane.lapie@…]

loader/wrapper.S unified diff, allows build on Macbook

[stephane.lapie@…]

loader/stubs.s unified diff, allows build on Macbook

[stephane.lapie@…]

loader/ldt_keeper.c patch, fixes mmap() feeding on /dev/zero, with mmap(MAP_ANON) with -DCONFIG_DARWIN

[stephane.lapie@…]

loader/ext.c patch, fixes mmap() feeding on /dev/zero, with mmap(MAP_ANON) with -DCONFIG_DARWIN

[stephane.lapie@…]

loader/ldt_keeper.c patch, fixes mmap() feeding on /dev/zero, with mmap(MAP_ANON) with -DCONFIG_DARWIN (proper diff

[stephane.lapie@…]

Result of executing "gdb mplayer" and loading a WMV9 file :

Entering DllMain(DLL_PROCESS_ATTACH) for /usr/local/lib/codecs/wmv9dmod.dll

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand.
0x8fe136e4 in dyld_stub_binding_helper_interface ()
(gdb)

Memory corruption occured somewhere ?

[stephane.lapie@…]

Step-by-step debugging gave this result :

(gdb) bt
#0 PE_InitDLL (wm=0x214da30, type=1, lpReserved=0x0) at pe_image.c:953
#1 0x000a0c91 in MODULE_InitDll (wm=0x214da30, type=1, lpReserved=0x0) at
module.c:158
#2 0x000a140c in LoadLibraryExA (libname=0x3d12a4 "wmv9dmod.dll", hfile=0,
flags=0) at module.c:254
#3 0x000a17ad in LoadLibraryA (libname=0x3d12a4 "wmv9dmod.dll") at module.c:577
#4 0x000b5ee6 in DMO_FilterCreate (dllname=0x3d12a4 "wmv9dmod.dll",
id=0x4d3bdc, in_fmt=0x214db94, out_fmt=0x214dbdc) at dmo.c:60
#5 0x000b4cf5 in DMO_VideoDecoder_Open (dllname=0x3d12a4 "wmv9dmod.dll",
guid=0x4d3bdc, format=0x210ff60, flip=0, maxauto=0) at DMO_VideoDecoder.c:188
#6 0x0008b17b in init (sh=0x210fec0) at vd_dmo.c:33
#7 0x00057436 in init_video (sh_video=0x210fec0, codecname=0x0, vfm=0x0,
status=1) at dec_video.c:243
#8 0x000576b1 in init_best_video_codec (sh_video=0x210fec0,
video_codec_list=0xbfffe86c, video_fm_list=0x0) at dec_video.c:289
#9 0x00007278 in main (argc=2, argv=0xbffffadc) at mplayer.c:3409
(gdb) step

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand.
0x8fe136e4 in dyld_stub_binding_helper_interface ()
(gdb) bt
#0 0x8fe136e4 in dyld_stub_binding_helper_interface ()
#1 0x00000000 in ?? ()
(gdb)

Things go boom after calling this :
pe_image.c:953:retv = entry( wm->module, type, lpReserved );

That means, when executing DLL code. Did something wrong occur with the loading
or anything ?

[stranche@…]

More annoying than the DLL loading (wich really seems to need an extensive
study), the fact that we must issue the configure options "--disable-win32
--disable-dshow --disable-mmx --disable-mmxext --disable-3dnow
--disable-3dnowext --disable-sse --disable-sse2 --disable-fastmemcpy" shows that
the configure and asm bits are not adapted to the core CPU and the GCC version
into Xcode.

Apple docs shows that mac asm is different than pc asm.

the Apple GCC is very intolerant with legacy code, makes sense since Apple
started with Core CPUs and so don't care about 386/486/586/686/athlon/etc
specific optimisations, worse some bits present in actual code makes it invalid
(for example loader/wrapper.S : both ".global" and ".globl" are used but the
first one is deprecated and supported for legacy in numerous compilers, but not
Xcode's one).

[stephane.lapie@…]

Obtained more detailed trace from GDB provided this result. Here is the call
trace a few instruction steps before it crashes :

#0 0x8fe136d0 in dyld_fast_stub_binding_helper_interface ()
#1 0x0059a37f in dyld_stub_pthread_mutex_init ()
#2 0x000afa53 in expmalloc (size=128) at win32.c:470
#3 0x15e20a45 in ?? ()
#4 0x000a7dce in PE_InitDLL (wm=0x214c7e0, type=1, lpReserved=0x0) at
pe_image.c:953
#5 0x000a3711 in MODULE_InitDll (wm=0x214c7e0, type=1, lpReserved=0x0) at
module.c:158
#6 0x000a3e8c in LoadLibraryExA (libname=0x3d3dd0 "wmv9dmod.dll", hfile=0,
flags=0) at module.c:254
#7 0x000a422d in LoadLibraryA (libname=0x3d3dd0 "wmv9dmod.dll") at module.c:577
#8 0x000b8936 in DMO_FilterCreate (dllname=0x3d3dd0 "wmv9dmod.dll",
id=0x4d6cfc, in_fmt=0x214c944, out_fmt=0x214c98c) at dmo.c:60
#9 0x000b7745 in DMO_VideoDecoder_Open (dllname=0x3d3dd0 "wmv9dmod.dll",
guid=0x4d6cfc, format=0x2110a90, flip=0, maxauto=0) at DMO_VideoDecoder.c:188
#10 0x0008dbfb in init (sh=0x2110c60) at vd_dmo.c:33
#11 0x00059eb6 in init_video (sh_video=0x2110c60, codecname=0x0, vfm=0x0,
status=1) at dec_video.c:243
#12 0x0005a131 in init_best_video_codec (sh_video=0x2110c60,
video_codec_list=0xbfffe83c, video_fm_list=0x0) at dec_video.c:289
#13 0x00007358 in main (argc=2, argv=0xbffffab4) at mplayer.c:3409

And here is the crash :
Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand.
0x8fe136e4 in dyld_stub_binding_helper_interface ()

This pthread_mutex_init call origins from the inlined function mreq_private,
which is why it does not appear in the backtrace.
#0 mreq_private (size=128, to_zero=0, type=0) at win32.c:378
Which line is : pthread_mutex_init(&memmut, NULL);

It seems that upon calling the pthread lib, the linker has a fit. Perhaps this
really reveals memory space corruption or anything nastier ?

Here is the disassembled memory dump at the crash point :
Dump of assembler code for function dyld_stub_binding_helper_interface:
0x8fe136d2 <dyld_stub_binding_helper_interface+0>: push %ebp
0x8fe136d3 <dyld_stub_binding_helper_interface+1>: mov %esp,%ebp
0x8fe136d5 <dyld_stub_binding_helper_interface+3>: sub $0x60,%esp
0x8fe136d8 <dyld_stub_binding_helper_interface+6>: mov %eax,8(%esp)
0x8fe136dc <dyld_stub_binding_helper_interface+10>: mov %ecx,12(%esp)
0x8fe136e0 <dyld_stub_binding_helper_interface+14>: mov %edx,16(%esp)
0x8fe136e4 <dyld_stub_binding_helper_interface+18>: movdqa %xmm0,32(%esp)

Still, this indicates one thing : after the entry() call which launches
DllMain(), and after we "dive" in the DLL code, things are still all right.
Then, the DLL code calls expmalloc() from win32.c, and emerges from unknown code
land. It's only after it breaks, which would indicate that DLL loading "works"
and doesn't provide garbled or messed up asm code.

[stephane.lapie@…]

After doing extensive tests on this specific code bit and finding out that there
is no memory corruption on the linker code after loading the DLL (a clean run
and disassembly of the function mplayer SIGILL's in proved this), I turned
myself to the register states and Intel instruction semantics :

Things go boom here :
0x8fe136e4 <dyld_stub_binding_helper_interface+18>: movdqa %xmm0,32(%esp)

And movdqa semantics are clear : "move aligned double quadword", with a 16-byte
alignment.

In a working context, this is the ESP register value :
esp 0xbffffab0 0xbffffab0 (aligned on 16 bytes, so it's all right)

In our broken context, this is the value :
esp 0xbfffdb28 0xbfffdb28 (ends with a 8, hence non-aligned.
Hence illegal operation)

This means that the DLL prepares it's stack before calling expmalloc(), and
gives it back to MPlayer code in a broken state :/

[stephane.lapie@…]

loader/win32.c patch, allows to clear DllMain loading, and execution up to a certain point... Not perfect at all.

[stephane.lapie@…]

(In reply to comment #34)

Created an attachment (id=239) [edit]
loader/win32.c patch, allows to clear DllMain loading, and execution up to a
certain point... Not perfect at all.

I tried patching every function so it creates a temporary proper %esp, and I
successfully went as far as clearing DllMain and the registry initialization.
Now, I still get the SIGILL error because of a call to a system function (it
goes through the dyld_stubs and *booms* because of invalid %esp), but I've
been farther than ever. Is there a way to transform the DLL stack preparation
code during the loading process ? This would perhaps be a cleaner way of doing it.

[stephane.lapie@…]

Win32 loader full diff between 1.0pre8 and my test version on Macbook. This finally enables the playback of WMV9 files using the DLL support. Bugs left : unknown as of now.

[stephane.lapie@…]

Success at last, it seems.

After some more toying with gdb, step by step execution and hacking, I traced
the last functions that still required the stack cleaner hack. Note that since
this hack shifts the stack address, it is wise to declare local variables (that
will actually be stored into CPU registers) and to get vital arguments ; or to
use the STACK_CLEANER_PREFIX/STACK_CLEANER_SUFFIX only on critical sections
(like functions that will be loaded from dynamic libs, thus that will invoke
dyld_stub_*).

As of now, I've tested this on i386/Darwin (Macbook) and it works. Loading of
DLL, "registry" emulation, playback, uninit, all of these should be okay.
Looking for testers. :)

[stranche@…]

WORKS !

loading of DLL codecs on OSX MacIntel now works with this patch, I insured
quality now that I have access to the machine (we were remotely on it by SSH and
VNC).

Now left :
1- clean the code to integrate it better so that it works on x86 pc and x86 mac,
or make conditional the use of code for each archi
2- make the Intel Core Duo processor correctly recognized (see bug #525)
2- make the MPlayer source compile out-of-the-box on OSX+Xcode running on
MacIntel, as for now we have to issue a LOT of -disable options at configure (as
shown at Comment #9 and Comment #13, this is due to the fact that ASM on x86 mac
is different than x86 pc.
This document could be a start
​http://developer.apple.com/documentation/DeveloperTools/Reference/Assembler/Assembler.pdf

bugs seen:
-when reading a WMV9 file you cannot obtain the time playing/remaining on the
OSD, the progress bar and the play/pause indicator works however.

[stranche@…]

(In reply to comment #37)

bugs seen:
-when reading a WMV9 file you cannot obtain the time playing/remaining on the
OSD, the progress bar and the play/pause indicator works however.

False alarm, it was only because there were no font in .mplayer/subfont.ttf,
when placing a font everything runs nicely.

[wxprojects@…]

I tried the patch and ran into a similar problem (stack corruption?) as post 30, only with
RegOpenKeyExA down the stack.

---

===============================================================
===========
Opening video decoder: [dmo] DMO video codecs

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand.
0x8fe13754 in dyld_stub_binding_helper_interface ()
(gdb) bt
#0 0x8fe13754 in dyld_stub_binding_helper_interface ()
#1 0x00000000 in ?? ()
#2 0x000ae548 in RegOpenKeyExA (key=-2147483647, subkey=0x153defb4 "Software
Microsoft\
\Scrunch
WMVideo", reserved=0, access=0, newkey=0xbfffe770) at registry.c:436
#3 0x000a8d7b in expRegOpenKeyA (hKey=-2147483647, lpSubKey=0x153defb4 "Software\
\Microsoft
Scrunch
WMVideo", phkResult=0xbfffe770) at win32.c:1958
#4 0x153e1f48 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(gdb) bt
#0 0x8fe13754 in dyld_stub_binding_helper_interface ()
#1 0x00000000 in ?? ()
#2 0x000ae548 in RegOpenKeyExA (key=-2147483647, subkey=0x153defb4 "Software
Microsoft\
\Scrunch
WMVideo", reserved=0, access=0, newkey=0xbfffe770) at registry.c:436
#3 0x000a8d7b in expRegOpenKeyA (hKey=-2147483647, lpSubKey=0x153defb4 "Software\
\Microsoft
Scrunch
WMVideo", phkResult=0xbfffe770) at win32.c:1958
#4 0x153e1f48 in ?? ()
(gdb) frame 2
#2 0x000ae548 in RegOpenKeyExA (key=-2147483647, subkey=0x153defb4 "Software
Microsoft\
\Scrunch
WMVideo", reserved=0, access=0, newkey=0xbfffe770) at registry.c:436
436 init_registry()
(gdb) frame 3
#3 0x000a8d7b in expRegOpenKeyA (hKey=-2147483647, lpSubKey=0x153defb4 "Software\
\Microsoft
Scrunch
WMVideo", phkResult=0xbfffe770) at win32.c:1958
1958 long result=RegOpenKeyExA(hKey, lpSubKey, 0, 0, phkResult);
(gdb) frame 4
#4 0x153e1f48 in ?? ()
(gdb) frame 0
#0 0x8fe13754 in dyld_stub_binding_helper_interface ()
(gdb) p/x $sp
$1 = 0xbfffe644
(gdb) frame 1
#1 0x00000000 in ?? ()
(gdb) p/x $sp
$2 = 0xbfffe6ac
(gdb) frame 2
#2 0x000ae548 in RegOpenKeyExA (key=-2147483647, subkey=0x153defb4 "Software
Microsoft\
\Scrunch
WMVideo", reserved=0, access=0, newkey=0xbfffe770) at registry.c:436
436 init_registry()
(gdb) p/x $sp
$3 = 0xbfffe704
(gdb) q

---

After a lot of debugging I finally figured out that if I changed

init_registry();

around line 436 in loader/registry.c to

if(!regs)

{

STACK_CLEANER_PREFIX;

init_registry();

STACK_CLEANER_SUFFIX;

}

it would work! I will add it runs really smooth as well.

Usually get a crash when exiting though... usually signal 10 or 11 in uninit_vo, i.e.

MPlayer interrupted by signal 10 in module: uninit_vo

• MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and won't help unless you provide this information when reporting a possible bug.(In reply to comment

#30)

Step-by-step debugging gave this result :

(gdb) bt
#0 PE_InitDLL (wm=0x214da30, type=1, lpReserved=0x0) at pe_image.c:953
#1 0x000a0c91 in MODULE_InitDll (wm=0x214da30, type=1, lpReserved=0x0) at
module.c:158
#2 0x000a140c in LoadLibraryExA (libname=0x3d12a4 "wmv9dmod.dll", hfile=0,
flags=0) at module.c:254
#3 0x000a17ad in LoadLibraryA (libname=0x3d12a4 "wmv9dmod.dll") at module.c:577
#4 0x000b5ee6 in DMO_FilterCreate (dllname=0x3d12a4 "wmv9dmod.dll",
id=0x4d3bdc, in_fmt=0x214db94, out_fmt=0x214dbdc) at dmo.c:60
#5 0x000b4cf5 in DMO_VideoDecoder_Open (dllname=0x3d12a4 "wmv9dmod.dll",
guid=0x4d3bdc, format=0x210ff60, flip=0, maxauto=0) at DMO_VideoDecoder.c:188
#6 0x0008b17b in init (sh=0x210fec0) at vd_dmo.c:33
#7 0x00057436 in init_video (sh_video=0x210fec0, codecname=0x0, vfm=0x0,
status=1) at dec_video.c:243
#8 0x000576b1 in init_best_video_codec (sh_video=0x210fec0,
video_codec_list=0xbfffe86c, video_fm_list=0x0) at dec_video.c:289
#9 0x00007278 in main (argc=2, argv=0xbffffadc) at mplayer.c:3409
(gdb) step

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand.
0x8fe136e4 in dyld_stub_binding_helper_interface ()
(gdb) bt
#0 0x8fe136e4 in dyld_stub_binding_helper_interface ()
#1 0x00000000 in ?? ()
(gdb)

Things go boom after calling this :
pe_image.c:953:retv = entry( wm->module, type, lpReserved );

That means, when executing DLL code. Did something wrong occur with the loading
or anything ?

[reimar]

I think we already use MAP_ANON in other places, and using /dev/zero has other
problems as well, so I think you could propose them on -dev-eng without that
CONFIG_DARWIN stuff and instead getting rid of that whole /dev/zero code.
I don't think the other stuff has much of a chance, esp. since it's (at least to
me) completely unclear _why_ it is needed on Mac and not on "normal" PCs.
Btw. does wine have a MacIntel port and if yes how did they solve the problem?

[stranche@…]

(In reply to comment #39)

Usually get a crash when exiting though... usually signal 10 or 11 in

uninit_vo, i.e.

MPlayer interrupted by signal 10 in module: uninit_vo

• MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and won't help unless you provide this information when reporting a possible

bug.(In reply to comment

#30)

Step-by-step debugging gave this result :

(gdb) bt
#0 PE_InitDLL (wm=0x214da30, type=1, lpReserved=0x0) at pe_image.c:953
#1 0x000a0c91 in MODULE_InitDll (wm=0x214da30, type=1, lpReserved=0x0) at
module.c:158
#2 0x000a140c in LoadLibraryExA (libname=0x3d12a4 "wmv9dmod.dll", hfile=0,
flags=0) at module.c:254
#3 0x000a17ad in LoadLibraryA (libname=0x3d12a4 "wmv9dmod.dll") at module.c:577
#4 0x000b5ee6 in DMO_FilterCreate (dllname=0x3d12a4 "wmv9dmod.dll",
id=0x4d3bdc, in_fmt=0x214db94, out_fmt=0x214dbdc) at dmo.c:60
#5 0x000b4cf5 in DMO_VideoDecoder_Open (dllname=0x3d12a4 "wmv9dmod.dll",
guid=0x4d3bdc, format=0x210ff60, flip=0, maxauto=0) at DMO_VideoDecoder.c:188
#6 0x0008b17b in init (sh=0x210fec0) at vd_dmo.c:33
#7 0x00057436 in init_video (sh_video=0x210fec0, codecname=0x0, vfm=0x0,
status=1) at dec_video.c:243
#8 0x000576b1 in init_best_video_codec (sh_video=0x210fec0,
video_codec_list=0xbfffe86c, video_fm_list=0x0) at dec_video.c:289
#9 0x00007278 in main (argc=2, argv=0xbffffadc) at mplayer.c:3409
(gdb) step

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand.
0x8fe136e4 in dyld_stub_binding_helper_interface ()
(gdb) bt
#0 0x8fe136e4 in dyld_stub_binding_helper_interface ()
#1 0x00000000 in ?? ()
(gdb)

Things go boom after calling this :
pe_image.c:953:retv = entry( wm->module, type, lpReserved );

That means, when executing DLL code. Did something wrong occur with the loading
or anything ?

Noy likely, this happens in MPlayer-1.0pre8 without the patch too as I descrided
in bug #531
Seems to be -vo related on OSX

[stephane.lapie@…]

(In reply to comment #40)

I think we already use MAP_ANON in other places, and using /dev/zero has other
problems as well, so I think you could propose them on -dev-eng without that
CONFIG_DARWIN stuff and instead getting rid of that whole /dev/zero code.
I don't think the other stuff has much of a chance, esp. since it's (at least to
me) completely unclear _why_ it is needed on Mac and not on "normal" PCs.
Btw. does wine have a MacIntel port and if yes how did they solve the problem?

I didn't check how Wine did it, but as I had explained in one of my previous
posts, this is actually a MacOS X issue, and not directly hardware-related.

Apple works with the assertion that the ESP register is 16-byte aligned (hence
it can use some optimisations, which the dynamic linker uses, a quick use of
disassemble command upon getting SIGILL confirms this).

This is the only reason that made me think up this hack : stacking up one more
frame and force ESP to be 16-byte aligned in this child frame. If not for this,
any dynamic call to a function goes boom, as seen. I don't know how wine sorts
this mess out, but I sure couldn't think up of any other way of doing it.

[diego@…]

A simple patch to achieve a similar result is at

​http://www.notcom.org/mplayer/windll-darwin.patch

[wxprojects@…]

(In reply to comment #43)

A simple patch to achieve a similar result is at

​http://www.notcom.org/mplayer/windll-darwin.patch

Hmmm, when running WMV3/9 with this patch on my intel macbook, I get:

MPlayer interrupted by signal 4 in module: init_video_codec

• MPlayer crashed by an 'Illegal Instruction'. It usually happens when you run it on a CPU different than the one it was compiled/optimized for. Verify this!
• MPlayer crashed by bad usage of CPU/FPU/RAM. Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
• MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and won't help unless you provide this information when reporting a possible bug.

/ GDB /
Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand.
0x8fe13754 in dyld_stub_binding_helper_interface ()
(gdb) bt
#0 0x8fe13754 in dyld_stub_binding_helper_interface ()
#1 0x00000000 in ?? ()
#2 0x000b581b in my_mreq (size=128, to_zero=0) at win32.c:470
#3 0x000bbe5e in expmalloc (size=128) at win32.c:3891
#4 0x14323a45 in ?? ()
#5 0x000b51e2 in PE_InitDLL (wm=0x134b3e0, type=1, lpReserved=0x0) at pe_image.c:953
#6 0x000b05b5 in MODULE_InitDll (wm=0x134b3e0, type=1, lpReserved=0x0) at module.c:161
#7 0x000b06fb in MODULE_DllProcessAttach (wm=0x134b3e0, lpReserved=0x0) at module.c:257
#8 0x000b0a2a in LoadLibraryExA (libname=0x41d834 "wmv9dmod.dll", hfile=0, flags=0) at
module.c:420
#9 0x000b142c in LoadLibraryA (libname=0x41d834 "wmv9dmod.dll") at module.c:580
#10 0x000c6b92 in DMO_FilterCreate ()
(gdb) frame 0
#0 0x8fe13754 in dyld_stub_binding_helper_interface ()
(gdb) p/x $sp
$1 = 0xbfffdba8
(gdb) frame 1
#1 0x00000000 in ?? ()
(gdb) p/x $sp
$2 = 0xbfffdc10
(gdb) frame 2
#2 0x000b581b in my_mreq (size=128, to_zero=0) at win32.c:470
470 return mreq_private(size, to_zero, AREATYPE_CLIENT);
(gdb) p/x $sp
$3 = 0xbfffdc58
(gdb) frame 3
#3 0x000bbe5e in expmalloc (size=128) at win32.c:3891
3891 void* result=my_mreq(size,0);
(gdb) p/x $sp
$4 = 0xbfffdc78
(gdb) frame 4
#4 0x14323a45 in ?? ()
(gdb) p/x $sp
$5 = 0xbfffdca8
(gdb)
/

[wxprojects@…]

Hacks for getting MPlayer to work in release mode on WikiServerGuy's MacBook

[wxprojects@…]

Hmmm. I tried this in release mode on my MacBook and got loads of (mostly
stack-related) problems. After a LOT of debugging and hacking I came up with
this patch, but unfortunately this one doesn't work in debug mode and crashes
on memcpy:

==========================================================================
Opening video decoder: [dmo] DMO video codecs
DMO dll supports VO Optimizations 0 1
DMO dll might use previous sample when requested

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xc00000d0
0xffff0939 in _memcpy () at
/System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h:189

189
/System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h:
No such file or directory.

in

/System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h

---

Hopefully this helps someone :\.

[diego@…]

(In reply to comment #44)

(In reply to comment #43)

A simple patch to achieve a similar result is at

​http://www.notcom.org/mplayer/windll-darwin.patch

Hmmm, when running WMV3/9 with this patch on my intel macbook, I get:

MPlayer interrupted by signal 4 in module: init_video_codec

OK, sorry I didn't mention this, you need to define the environment variable
DYLD_BIND_AT_LAUNCH for this to work, read all the gory details in the thread on
mplayer-dev-eng:
​http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2006-July/044727.html

[stephane.lapie@…]

(In reply to comment #46)

OK, sorry I didn't mention this, you need to define the environment variable
DYLD_BIND_AT_LAUNCH for this to work, read all the gory details in the thread on
mplayer-dev-eng:
​http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2006-July/044727.html

Surely, this should be the cleanest way of avoiding the dyld's functions (if one
does not mind having to set this environment variable; imho a program's
behaviour shouldn't change that much just because a variable as been set/unset),
but what if another obscure Apple library required alignment for the ESP register ?

Of course, the answer would probably be "functions called from the Win32
compatibility functions shouldn't have this issue", but still, I'm asking ;)

[wxprojects@…]

MPlayer intel mac dll fix patch ("cleaned up" version of Valtteri Vuorikoski's)

[wxprojects@…]

This is a "cleaned up" version of Valtteri Vuorikoski's from the mailing lists.
It is cleaned up in the sense that I've tested it on two different linux
distributions and windows as well. I had to move some files around, tweak some
makefiles, and expand stubs.s into two files - stubs.s and stubs_bsd.s - for it
to compile correctly on windows and unix (they don't like the conditional
directives)

[stranche@…]

Hi to every reader of this bug.

lots of people said that continuing on supporting the windows DLL for the
MacIntel was unnecessary since the Google Summer of Code project for VC1 in
FFMpeg wwas on the rails.

However, even with such a huge (and very nice too) work, this project is still
far from completely satisfactory. As you can see in bug #551 some files still
need the use of the DLL to be playable.

Therefore I would really like to see the inclusion of the changes made by
Stephane Lapie (see comment #36 and followings), to be able to resolve this
problem...

[nicolas.plourde@…]

latest code solve all remaining issues on intel osx.

[stranche@…]

Not quite Ok yet.

SVN taken 29 nov at 18h20 (paris time)

You still have to compile with

./configure --disable-mp3lib

to be able to compile then use

./mplayer -demuxer lavf

else you got garble sound.

then if you try to play WMV files you get

Playing ../../Documents/video[wm9_VCM].avi.
AVI file format detected.
VIDEO: [WMV3] 640x480 24bpp 23.976 fps 1020.8 kbps (124.6 kbyte/s)
==========================================================================
Opening video decoder: [dmo] DMO video codecs
WARNING: Attempting to use DLL codecs but environment variable

DYLD_BIND_AT_LAUNCH not set. This will likely crash.

MPlayer interrupted by signal 4 in module: init_video_codec

• MPlayer crashed by an 'Illegal Instruction'. It usually happens when you run it on a CPU different than the one it was compiled/optimized for. Verify this!
• MPlayer crashed by bad usage of CPU/FPU/RAM. Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
• MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and won't help unless you provide this information when reporting a possible bug.

is there something else to be done at configure time ?

[stranche@…]

(In reply to comment #51)

then if you try to play WMV files you get

Playing ../../Documents/video[wm9_VCM].avi.
AVI file format detected.
VIDEO: [WMV3] 640x480 24bpp 23.976 fps 1020.8 kbps (124.6 kbyte/s)
==========================================================================
Opening video decoder: [dmo] DMO video codecs
WARNING: Attempting to use DLL codecs but environment variable

DYLD_BIND_AT_LAUNCH not set. This will likely crash.

MPlayer interrupted by signal 4 in module: init_video_codec

• MPlayer crashed by an 'Illegal Instruction'. It usually happens when you run it on a CPU different than the one it was compiled/optimized for. Verify this!
• MPlayer crashed by bad usage of CPU/FPU/RAM. Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
• MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and won't help unless you provide this information when reporting a possible bug.

Okay, I got it

You have to do

export DYLD_BIND_AT_LAUNCH=/usr/local/lib/codecs/ (or wherever are the DLL)

however this path is detected at ./configure time to set enable/disable the
win32 compilation parameter, therefore shouldn't this DYLD_BIND_AT_LAUNCH
environment variable be in the mplayer executable? or maybe as a parameter in
~/.mplayer/config ?

[reimar]

You don't have to set DYLD_BIND_AT_LAUNCH to you path, you just have to _set_
it. It should not matter what you set it to (though setting it to "1" would be
a sensible choice).
And please be more specific about your mp3lib compilations problems, I am not
aware of any more.

[stranche@…]

(In reply to comment #53)

You don't have to set DYLD_BIND_AT_LAUNCH to you path, you just have to _set_
it.

I don't get what you mean here

And please be more specific about your mp3lib compilations problems, I am not
aware of any more.

you can see it at bug #549 starting at comment #12

[reimar]

You don't have to set DYLD_BIND_AT_LAUNCH to you path, you just have to
_set_ it.

I don't get what you mean here

export DYLD_BIND_AT_LAUNCH=1

And please be more specific about your mp3lib compilations problems, I am
not aware of any more.

you can see it at bug #549 starting at comment #12

There is nothing about mp3lib compilation there.
Why does it not compile without --disable-mp3lib? What is the problem?

[stranche@…]

(In reply to comment #55)

export DYLD_BIND_AT_LAUNCH=1

Okay I see, however there should be a way to simplify this

And please be more specific about your mp3lib compilations problems, I am
not aware of any more.

Okay, the Pb is that when you compile without -disable-mp3lib your compile will
fail like this :

make -C mp3lib
cc -c -I. -I.. -Wdeclaration-after-statement -O4 -march=pentium-m
-mtune=pentium-m -pipe -ffast-math -fomit-frame-pointer -mdynamic-no-pic
-falign-loops=16 -DSYS_DARWIN -DCONFIG_DARWIN -shared-libgcc -arch i386
-isysroot /Developer/SDKs/MacOSX10.4u.sdk -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I/usr/local/include
-I/usr/X11R6/include -o dct64_MMX.o dct64_MMX.c
{standard input}:11:Missing operand value assumed absolute 0.
make[1]: * [dct64_MMX.o] Error 1
make: * [mp3lib/libMP3.a] Error 2

and if you compile with it, you will have a really awful sound if you don't use
the -demuxer lavf switch when playing with the mplayer binary created.

that's what I reported in the bug #549 I gave in reference, this issue asn't
been adressed since.

[nicolas.plourde@…]

I was not able to reproduce the build break with mp3lib

[stranche@…]

(In reply to comment #57)

I was not able to reproduce the build break with mp3lib

This is weird that you can compile it without error since this happens since
pre8 and Reimar seems to know about it too (see comment #9 on bug #549).

For the record, compile does not crash on PPC OSX

[nicolas.plourde@…]

I use xcode 2.4.1 and osx 10.4.8 with all latest patch. Make sure to run make distclean. Reimar fixed the
remaining problem in mp3lib last week.

[stranche@…]

(In reply to comment #59)

I use xcode 2.4.1 and osx 10.4.8 with all latest patch.

Damn, now I see what the problem is...
I was busy lately and didn't even saw the Xcode 2.4.1 release and was still
using the 2.3 version, sorry about this.

Since this Xcode release is mandatory shouldn't there be a warning or a note
somewhere?

[nicolas.plourde@…]

Latest apple gcc needed for compilation