The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

SDL Forum Index
SDL
Simple Directmedia Layer Forums
CPU specific build flags for OS X Universal Binaries
E. Wing
Guest
Post Posted: Thu Jan 19, 2006 1:07 am
So I think we're close to getting the Universal Binaries finished. The
tricky part has been figuring how to maintain 10.2 compatibility in
this whole process. I think we're finally past this (pending on some
final 10.2 test results).


One thing I still need help with is what build flags should I be
defining to enable CPU specific optimizations like Altivec or SSE/MMX?
I know how to pass architecture specific flags in Xcode, but I don't
know what actual flags (if any) I need to use for SDL.

Currently, for PowerPC I think I need -DGCC_ALTIVEC
-DUSE_ALTIVEC_BLITTERS. Are there any others? And I'm not sure what
flags (if any) I need for Intel. Also, does additional code need to be
included in the Xcode project for x86? (The Xcode project seems to
omit non-Mac code.) Currently, the x86 side compiles without any
flags, but I don't know if it gets any SSE capabilities by default.

Thanks,
Eric
CPU specific build flags for OS X Universal Binaries
Stephane Marchesin
Guest
Post Posted: Thu Jan 19, 2006 1:49 am
E. Wing wrote:

Quote:
So I think we're close to getting the Universal Binaries finished. The
tricky part has been figuring how to maintain 10.2 compatibility in
this whole process. I think we're finally past this (pending on some
final 10.2 test results).


One thing I still need help with is what build flags should I be
defining to enable CPU specific optimizations like Altivec or SSE/MMX?
I know how to pass architecture specific flags in Xcode, but I don't
know what actual flags (if any) I need to use for SDL.

Currently, for PowerPC I think I need -DGCC_ALTIVEC
-DUSE_ALTIVEC_BLITTERS. Are there any others? And I'm not sure what
flags (if any) I need for Intel. Also, does additional code need to be
included in the Xcode project for x86? (The Xcode project seems to
omit non-Mac code.) Currently, the x86 side compiles without any
flags, but I don't know if it gets any SSE capabilities by default.

You should define USE_ASMBLIT. Then the cpu mmx/sse/whatever available
will be used (you also need to use a gcc compiler with i386 defined).
You will also need nasm to compile the hermes blitters. Man, I feel I've
been meaning to rewrite these blitters for gcc for ages...

Stephane
CPU specific build flags for OS X Universal Binaries
Bill Kendrick
Guest
Post Posted: Thu Jan 19, 2006 2:40 am
Sorry to hijack the thread... but the following stood out to me :^)

On Wed, Jan 18, 2006 at 05:07:38PM -0800, E. Wing wrote:
Quote:
So I think we're close to getting the Universal Binaries finished. The
tricky part has been figuring how to maintain 10.2 compatibility in
this whole process. I think we're finally past this (pending on some
final 10.2 test results).

I just got set up to build Tux Paint for OS X using Xcode.
Unfortunately, when I hit the "10.2.8 compatibility" switch, suddenly
things no longer link.

I have a feeling it might be Fink-related. (We pick up libiconv and
libintl and I think the SDL-and-friends libs from Fink, and the
SDL-and-friends frameworks for Xcode directly from libSDL.org.)

Anyone out here still able to do 10.2.8 builds and would like to give
us a hand? :^) (I can probably walk through all this on an weekday
evening (Pacific time) or weekend, via IRC.)

--
-bill! Tux Paint 2006 wall calendar,
bill at newbreedsoftware.com CDROM, bumper sticker & apparel
http://www.newbreedsoftware.com/ http://www.cafepress.com/newbreedsw

PS - Thanks to Ryan/icculus for the Mac mini and Martin Fuhrer for the
"how to build Tux Paint on OS X" walk-thru last weekend. :^)
CPU specific build flags for OS X Universal Binaries
E. Wing
Guest
Post Posted: Mon Jan 23, 2006 10:28 pm
Quote:
From: Stephane Marchesin <stephane.marchesin at wanadoo.fr>
No, .align X aligns over the next X boundary. He's probably confusing it
with .p2align X which aligns over the next 2^X.
Try it if you don't believe me (and here I hope the gcc guys didn't
change the .align semantics in a recent version Wink

As I said, I know nothing about this and am perfectly happy to take
your word on it Smile I actually don't have the ability to test anything
though. I only have PPC based Macs. I'm just setting up the build
system (and trying to get some binaries ready).

Quote:
Well, some of this code is not PIC-clean, since no one made it PIC-clean
so far. However, even though this could probably cause crashes at
runtime with some compilers on some systems, this shouldn't prevent it
from compiling.

To be perfectly honest, I don't like this code because it adds a
dependency on nasm, and thus can't be used on platforms with no nasm
support (qnx for example), because it's not PIC-clean, and because some
ld versions are buggy when linking nasm files. A gcc rewrite has been
for a long time in my todo list, I even started it IIRC...

Quote:
Quote:
Quote:
Quote:
Well, you definitely do not want to do that. I think the right way is to
find how to do conditional file compilation in Xcode. This has to exist
Smile
Quote:

Unfortunately, I'm fairly certain this doesn't exist. That's why I'm
looking for something like a preprocessor trick. Any other ideas?

Yet another reason to rewrite that stuff in gcc style, where you could
simply use gcc #ifdefs :)

Also, to use some nasm-specific preprocessor stuff, you'd need to have
nasm (an x86-specific assembler) to work under powerpc, if only in order
to parse the .asm files. It sounds like there is very little chance this
can be accomplished.


Okay, so I think we've gone as far as we can to support the Intel Macs
until the assembly code is rewritten. It you could bump up the
priority on your to-do list, I'm sure x86 Mac users would be grateful
:)

In the meantime, I guess I will setup the build system to not do any
architecture specific optimizations for x86.

Thanks,
Eric