[SDL] SDL on MacOSX/x86...

Ryan C. Gordon icculus at clutteredmind.org
Wed Jun 8 00:36:44 PDT 2005


> I built from the command line directly on one of these boxes; the Xcode 
> project files (and the Makefiles) will need changes to build a 
> "universal" binary that'll run on either platform. The configure scripts 
> build x86 binaries by default on these machines and ppc binaries on 
> "normal" Macs right now. I'm not sure what precisely needs changing in 
> this case, so I'll defer to someone else, but the code itself seems good 
> to go.

Following up after a few hours of harassing Apple engineers...If someone 
wants to attack the configure scripts, here's what seems to work:

If you are on a MacOS system and using gcc 4.0 or later, you can specify 
"-arch ppc -arch i386" to both the compilers and linker and you'll get a 
Universal Binary ("Fat Binary", whatever). Object files built this way 
basically run the compiler twice, and both x86 and ppc code is kept in 
the same .o file. Command lines that apply to only one architecture 
(like, say, -faltivec or -msse) are safe to put on the command line; the 
  tools will ignore those that don't apply to a given portion of the 
task, but Apple engineers suggest that it might be smart to avoid really 
esoteric gcc options that might not be caught by the existing mechanism.

Since you get two seperate compiles for each object file, you can 
seperate out arch-specific code with #ifdefs and it'll Do The Right 
Thing when it builds each, so this:

#ifdef __POWERPC__
// some altivec code
#elif __SSE__
// some SSE code
#endif

...will use the right code in each part of the binary, and not try to 
compile the other part. I don't know what the recommended preprocessor 
definitions are, but Apple documentation says not to use __POWERPC__ 
when you mean "__BIG_ENDIAN__" ... which I presume is so no one has to 
write these emails again in 20 years.  If you're blocking out Altivec 
code, you can use __VEC__, apparently, and __POWERPC__ is probably okay 
if you have legitimate inline assembly (like the lhbrx opcode for 
byteswapping, etc).

SDL_byteorder.h detects the platform currently because the current gcc 
build predefines __i386__, which lands in the right place in that 
header. I don't know if this is the recommended way to do it, but oh well.

Clearing up previous lies:
- You need XCode 2.1 or later. gcc4.0 that ships with Tiger is 
insufficient. You'll also need the Universal Binary support (I forget 
the exact name), which is NOT installed by default in Xcode 2.1...you'll 
have to click the "Customize" button in the installer and find it.

- If you aren't on a system with Universal Binaries for all the system 
libraries (i.e. - you're on any Mac shipping today), then "-arch ppc 
-arch i386" won't be enough, since gcc will try to link against your 
existing system libs and won't find the x86 ones. This IS sufficient on 
the demo x86 Macs here at WWDC, and eventually, everywhere, but for now, 
you need to tell it to use a different set of System files with these 
command line arguments:

   -isysroot /Developer/SDKs/MacOSX10.4u.sdk
   -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk

(or wherever that got installed on your system)

You may or may not need to set the "MACOSX_DEPLOYMENT_TARGET" 
environment variable to "10.4"...XCode does this, but I don't think I 
had it set for other things.

That's about the entire brain dump. Likely for the next few months, this 
isn't high-priority, until people want to support both an x86 and PPC 
mac with one binary...people building for themselves "The Unix Way" will 
get the proper build for their system already with what's in CVS.

--ryan.





More information about the SDL mailing list