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.
sounds so, soo ancient. but that’s what they