[MPlayer-dev-eng] shared liba52 and mm_accel macros

Reimar Döffinger Reimar.Doeffinger at stud.uni-karlsruhe.de
Sun Apr 1 17:55:18 CEST 2007

On Mon, Apr 02, 2007 at 01:24:28AM +1000, Finn Thain wrote:
> The assumption here is that, come runtime, the architecture has been 
> determined already, so reuse the same value. Well, I'm not comfortable 
> with that, since I know that Mac OS X can run powerpc binaries alongside 
> intel binaries (and I seem to recall that an emulated powerpc app can 
> dynamically link with a native x86 dylib (?)).

I'm quite certain that not, maybe you can compile PPC and x86 code into
one dylib, but I don't think anyone seriously ever tried to do emulation
this way. Also because it means you have to convert ABI and calling
conventions, and with functions like printf that is nearly impossible.

> I concluded that the whole idea of choosing an optimisation via a library 
> API is broken -- in this case a52_init(uint32_t mm_accel). It should be 
> taken care of by the library at compile time (it's not like we don't have 
> the source) or else CPU features should be detected automatically at 
> runtime by the library. It shouldn't be part of the API. (Or else 
> libraries are intended to be forked and bundled as they are in mplayer et 
> al.)

I strongly disagree, simply due to the fact that Altivec detection on
Linux simply is _impossible_ inside a library. Yes, libavcodec does it,
but the code is absolutely broken i.e. incorrect, completely lacking
thread safety and other problems, and this is _not_ fixable.
Altivec can only be autodetected in the main() function.

Reimar Döffinger

More information about the MPlayer-dev-eng mailing list