Re: How do I build universal binaries for libraries with endian-specific code
Re: How do I build universal binaries for libraries with endian-specific code
- Subject: Re: How do I build universal binaries for libraries with endian-specific code
- From: Norm Schuster <email@hidden>
- Date: Fri, 30 Sep 2005 17:08:13 -0700
Title: Re: How do I build universal binaries for libraries with endian-specific code
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.
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.
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...
On 9/30/05 4:44 PM, "Eric Albert" <email@hidden> wrote:
On Sep 30, 2005, at 4:33 PM, Norm Schuster wrote:
I'm currently in the process of migrating to XCode and probably the biggest stumbling block is how to deal with c/c++ libraries that have endian-specific code that is included or removed at compile time. For example:
#if __LITTLE_ENDIAN__
// do this
#elif __BIG_ENDIAN__
// do that
#endif
Apple's "Universal Binary Programming Guidelines" doesn't say much about this except "Use the __BIG_ENDIAN__ and __LITTLE_ENDIAN__ macros only if you must" but I fail to see how this works unless it builds two separate variants for running on PowerPC and Intel. Can anyone enlighten me on how exactly this works.
The "only if you must" part comes about because nearly all of the cases in which folks want to write "endian-specific" code involves byte-swapping. Whenever you want to swap bytes, you should use OSByteOrder.h, CFByteOrder.h, NSByteOrder.h, or Endian.h, and regardless of which header you use, the compiler won't emit any code that it doesn't have to.
For example, if you're compiling for PowerPC and you call CFSwapInt32HostToBig, the compiler will do nothing on PowerPC and only emit code on Intel.
This lets you avoid #ifdefs in your code and makes your code easier to read.
If you have architecture-specific code that does something other than byte swapping (which is rare), use the appropriate #ifdef. For example, if it's code specific to PowerPC hardware that doesn't exist on any other architecture, use #if __ppc__. But if it's code that would be appropriate to all little-endian systems, use #if __LITTLE_ENDIAN__.
Also, why didn't Apple just add another folder in the bundle containing two different executable files like it did with PEF and Mach-)? Why not have a bundle structure like this:
/Contents/MacOSClassic/PEF_Executable_PPC
/Contents/MacOS/MachO_Exectuable_PPC
/Contents/MacOSIntel/MachO_Executable_Intel
This would have made more sense rather than having a "fat" application with no obvious way to make it leaner.
I'm not sure what you mean by making it leaner. Packaging the two sides of the binary into a single Mach-O executable, as we do today, incurs no performance penalty at all -- only the side that you're running gets mapped in -- and is about as clean as you can get.
Hope this helps,
Eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden