[MPlayer-dev-eng] [PATCH] Windows DLL support for OS X/Intel (cleaned version)

[Valtteri Vuorikoski]

Stephane Lapie <darksoul at darkbsd.org> writes:

> I was wondering (as I posted on the Bugzilla) whether this would completely
> solve the issue. Wouldn't another function call to a lib provided by Apple
> from the Win32 compatibility functions, require an aligned ESP register and
> then crash with a SIGILL again ?

What do you mean by "another function call"? When I was debugging this
issue, the problem appeared to be with the lazy binding of functions
from shared libraries (crash inside dylib1.o). With lazy binding
disabled, this particular problem disappears. Whether other problems
might appear with DLLs other than the ones I've tested, I don't know.

> Is it really proper to ask the user to do this ? Usually (but that's just my
> opinion there) a program's behaviour should not change that much because of
> an environment variable. Then again, yes, it's the cleanest way yet to get the
> job done properly.

Well, there's the MH_BINDATLOAD header flag which has the same effect
but is currently apparently ignored by dyld. Maybe Apple will fix that
some day. One alternative not requiring much code but being rather
evil I thought of would be to do some symbol-table hackery to
intercept calls to dylib1.o functions and set up a nice and clean
environment for the dynamic linker when it's invoked. But I don't
really know whether this is worth the trouble and hackiness.

Of course it's not nice to have to set variables to tweak the dynamic
linker, but given the alternatives I don't think it's
unreasonable. Additionally, I suspect many (most?) OS X users will use
the GUI, which can (and will, when I have time to work on it) hide the
issue altogether.

 -v