"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."
Post a Comment
Member since:
2005-10-30
Member since:2006-01-31
Member since:2005-11-16
"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.
Member since:2005-07-07
Member since:
2006-02-28
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
Member since:
2006-04-26
Member since:2006-02-28
Member since:
2005-08-18
Member since:2006-02-28
Member since:
2005-07-14
Member since:
2005-11-11
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.
Member since:2005-11-10
Member since:
2005-09-14
