On Sep 30, 2005, at 5:08 PM, Norm Schuster wrote: Thanks for your response. However, the problem I'm dealing with is legacy code (up to 20 years old) that has these endian-specific parts to it. Some of it is in-house while other libraries are open source such as libtiff (http://www.remotesensing.org/libtiff/). Are you saying that I would have to modify these libraries to use the CFSwap***HostToBig functions? This sounds like a lot of work and I would be touching code that I'm unfamiliar with.
In most cases I would expect those libraries to work out of the box. If they run on Windows or Unix (as libtiff does), they should work fine. (TIFF code in particular is already like to be endian-friendly because TIFFs can be both big- and little-endian.) Otherwise yes, you'll have to add byte-swapping code to them. Is there no way to build a separate PPC version and a separate Intel version? Right now I'm leaning towards the solution of building two separate applications - one for PPC (running on OS 10.3x and higher) and an intel version (running on OS 10.4.x and higher). For the latter I would have to define the LITTLE_ENDIAN symbol (if I was building on a PPC mac) so that the libraries would build correctly. Not the most elegant solution and certainly not "universal" but in a lot of ways less risky.
I think you're misunderstanding how this works. With Xcode's Architectures setting, you can build your application for PowerPC, Intel, or both. When you build for both, the compiler actually runs twice, once building for PowerPC and once building for Intel.
Whenever the compiler builds code for PowerPC, it defines __BIG_ENDIAN__. Whenever the compiler builds code for Intel, it defines __LITTLE_ENDIAN__. It doesn't matter what system you're building on...the symbols are defined for the architecture you're building for. As for being leaner, I noticed that the executable in a universal binary application is about twice the size of a PPC binary application; both built with XCode. So, if these executables were separate files in separate folders, you could simply discard the one you didn't need thus reducing the size of the application stored on your disk. Just an observation... Disk space is cheap. Just as importantly, we've found that with resources, localizations, etc., the impact of doubling the size of the executable is far less than doubling the size of most applications. For Mac OS X, when we ran a test a while back the overall impact was roughly 30%, not the 100% you would've expected if everything doubled in size.
That said, you can use the 'lipo' command line tool to remove architectures from a universal binary if you want to.
-Eric
|