Submitted by “Mac OS X includes many open source projects that contribute to the stability and robustness of the system. While Apple provides working versions of these for both PowerPC and Intel architectures, sometimes you want to build your own to tune performance or enable custom features. Plus, distributing a single binary is often preferable to keeping track of separate, architecture-specific binaries. These objectives can be accomplished by building the project as a Universal Binary, a file that contains code for both the PowerPC and Intel architectures.”
This article shows how to use Xcode (using Xcode 2.2.1) to construct a make-based project that builds OpenSSL as a Universal Binary.”
Building an Open Source Universal Binary
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
if one can use the universal binary to build 2 different builds, one for say x86-Yonah, and one for x86-Memron (when it comes out). So that we could build a version that runs optimized on any platform it might encounter?
Essentially, no… The universal part refers to X86 and PPC. Thats not to say there arent CPU specific optimizations, but you would’nt get 2 X86 builds with a Universal binary.
“Essentially, no… The universal part refers to X86 and PPC. Thats not to say there arent CPU specific optimizations, but you would’nt get 2 X86 builds with a Universal binary.”
Actually it does. Universal Binary is just the the new name of a technology which has existed in OS X for a while called fat binaries, where several executables can be packaged in the same binary.
There is basically nothing limiting you to build an Universal Binary that has more than two executables. The technology is powerful enough to allow developpers of applications that are sensitive to performance to build a Universal binary that contains executables optimised for specific processor architectures.
For example its is possible to build a Universal binary that contains an executable optimised for G3, amother one for G4, another one for 32 bits G5, another one for 64 bits G5 (PowerPc 64) and another one for X86. You will notice that this also the same solution that it is used to provide a 32 bits executable of one application and the executable of the same app for 64 bits in the same binary.
So i would rather think that for X86, the Universal Binary format would also allow to combine several x86 executables (as it does today for PowerPc) optimised for different x86 architectures. So for example if developpers want to provide an 64 bits application that runs on 64 bits Core architecture they can do it and in the same time they can still provide a 32 bits executable of their app in the same binary for 32 bits Yonah class processors.
Universal Binaries are therefore expendable to however architectures are needed. It is possible to imagine that if a developer wish it, he can build an Universal Binary that contains executables for G3, G4, G5 32 bits, G5 64 bits , Intel Yonah, Intel Core Architecture, Intel Core Architecture 64 bits, providing that his application is performance sensitive and requires the optimisation for a given architecture.
Does anyone really think that Merom and Yonah are significantly different that such optimizations are warranted?
I don’t know why doc writers used XCode for this example, there is strictly no need of XCode for running their scripts.
Anyway, it could be a good thing if this process would be cleanly included to the ./configure && make && make install process without worring of Mac stuff.
Answer to myself : http://developer.apple.com/technotes/tn2005/tn2137.html seems pretty clean
Edited 2006-04-26 10:52
NeXT called it “fat binary” about a decade ago.
A nice idea, indeed.
Could be subtitled “compile once, run everywhere”…
err, actually it’s compile twice, do some lipo stuff AND THEN run everywhere.
But i agree, nice, confortable for user. But no magic.
“A nice idea, indeed.”
Until you support more than a handfull of different architectures
Fat indeed.
Could be very fun to have a whole debian system in fat binaries.
Hey ! my 13 CDs distro grew up to 58 !
This is awesome, I was going to need to build some Universal libraries and command-line programs at work. Nice timing!
– chrish
Until you support more than a handfull of different architectures
Fat indeed.
Hey ! my 13 CDs distro grew up to 58 !
Funny, but obviously a bit of an exaggeration. Within a universal binary, the binaries are duplicated, not all the data. Binaries themselves are usually a small percentage of the size of a package.
As an extreme example (because I’ve been playing it lately): Farcry. Whole thing takes up 3.2 GB on my drive, of which .exe and .dlls make up only 28.2 MB. Double, triple that even and it increases the size of the package by a relatively tiny amount.
Like I said, extreme example, but the conclusion would hold true for other packages, if to a lesser degree.
There’s usually resources inside a Windows Executable too that adds to the fat. As a more accurate example I took GarageBand on the Mac (100 MB app bundle) and stripped all the PPC binaries out of it, reducing the bundle to 84.8 MB, a saving of 15.2 MB
Considering that Merom is a completely new microarchitecture whilst Yonah is essentially a slightly souped up dual core Pentium M, yes that would seem to be the case.