[MPlayer-dev-eng] [Q] How to build a universal binary for the Mac OS X?

Rich Felker dalias at aerifal.cx
Tue Sep 26 02:22:27 CEST 2006


On Mon, Sep 25, 2006 at 11:03:29PM +0200, Chris Roccati wrote:
> 
> On 25 Sep 2006, at 18:01 , Rich Felker wrote:
> >IT ABSOLUTELY IS NOT! If you're asking how to do something that's FOR
> >YOUR SAKE, it's a user question. Period. It doesn't matter if that
> 
> It's not.

Asking "How do I...?" is almost always a user question. This is our
definition of user questions. If you don't like that, too bad. This is
the way it's always been.

> For example building for intel macs using powerpc systems  
> (currently non working) falls under the category of improving the  
> mplayer build system to provide a more consistent cross-compiling  
> environment.

In a very twisted, disgusting sense of "improving"...

> I don't really see how adding a few lines to a 8445 lines script (to  
> support a relatively widespread operating system) can be called  
> bloat, expecially considering that in the source code you can even  
> find workarounds for the far more marginal AmigaOS4 and MorphOS.

It's not a few lines. You'd have to make the whole build process build
two object files for each target, which means supporting out-of-tree
build, two separate sets of build config, etc. This kind of special
casing for a disgusting idiot-centric binary backwards compatibility
layer of an idiot-centric proprietary OS does NOT belong in a build
system.

Should every project adapt itself to the stupidities of MacOS? NO! Mac
users wanting to compile binaries can do it the proper way. And the
majority of the Mac users who don't even know what "compile" means can
just download the "universal binary" (should be called "bloated
binary") that someone else made for them...

> As a sidenote, the currently available "official" MacOS binary *IS*  
> an universal binary: it would be interesting for the MacOS developers  
> to know how it was built.

You build the two separately then use the program that combines
them... Not difficult...

Rich




More information about the MPlayer-dev-eng mailing list