[MPlayer-dev-eng] [Q] How to build a universal binary for the Mac OS X?
Chris Zubrzycki
beren at mac.com
Tue Sep 26 02:29:16 CEST 2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sep 25, 2006, at 8:22 PM, Rich Felker wrote:
> 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.
Ok, that is a bit harsh. 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.
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
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 ;-)
>> 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...
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 :)
- -chris zubrzycki
- - --
PGP public key: http://homepage.mac.com/beren/publickey.txt
ID: 0xA2ABC070
Fingerprint: 26B0 BA6B A409 FA83 42B3 1688 FBF9 8232 A2AB C070
_________________________________________________
This message is encoded using the Rot-26 encoding method.
Unauthorized decoding of this message may result in extreme penalties
under the DMCA. These penalties include, but are not limited to: US
$100,000 fine, life imprisonment, castration, death, limp hair,
terminal halitosis, and amputation of the extremities.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: Please sign reply-http://www.gnupg.org
iEYEARECAAYFAkUYdF8ACgkQ+/mCMqKrwHD3SQCghdMT3cGBwVuwbWENbjS6DEwg
iIUAnjkO6LgagkBHN1M7UEsNL5FhwbrI
=5ibZ
-----END PGP SIGNATURE-----
More information about the MPlayer-dev-eng
mailing list