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

[Rich Felker]

On Mon, Sep 25, 2006 at 08:29:16PM -0400, Chris Zubrzycki wrote:
> >>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.
> 
> Ok, that is a bit harsh.

No it's not. Anything that increases size and complexity for the sake
of binary compatibility is disgusting bloat. Free software is not
about binaries. Look at the BSDs for an example of how things should
be done (make world, anyone??) and compare Linux/glibc with its hordes
of legacy 16bit/32bit syscalls and libc symbol versioning crap. Not
only does it increase size, but no one except experts understands all
the crap, defeating one of the primary purposes of free software which
is ordinary people being able to understand, learn from, and modify
the code.

> Multi-arch files are very cool, and not as  
> bloated as you might think. 32/64bit ppc/intel binaries are very  
> convenient, especially when you have them all running the same OS.  

This means you'll waste several times the memory, having two or more
versions of each shared library mapped constantly as well. Just
brilliant....

> Most people don't even realize or care the processor that's in their  
> machine, as long as the apps they have installed work. With the  

These people are otherwise known as lusers.

Seriously, I acknowledge that not everyone wants to know or care how
their computer works. But this is something like knowing whether your
car needs gasoline or diesel! It's not too much to ask for people to
know the cpu arch of their machine!

> newest builds of most apps, people can just have the same app on any  
> of their machines or move them back and forth transparently. It's  
> like the endian issues, only on a much larger scale ;-)

Moving binaries between machines does not work anyway unless they all
have the same OS/distro, the same versions of all shared library
dependencies, etc. DLL hell at its finest.

> >You build the two separately then use the program that combines
> >them... Not difficult...
> 
> Yes, this is why fink will probably never be universal. We already  
> have a method of separating the different architectures, and while  
> 70% of projects can be easily tuned to build fat, the others, like  
> mplayer, are a bear, because of things like defines based on the  
> target system and processor, assembly, etc. Sometimes it's easier  
> just to build twice :)

Yes indeed. You should just build twice. Ordinary users compiling from
source do not have to care about this anyway because they will just
build the right version for their host system. Only packagers care.

Rich