SDL on MacOSX/x86

I spent some time in the lab Apple has set up at WWDC for people to play
around with their software on an Intel-based Mac platform.

SDL compiles and runs on the Intel MacOSX machines out of the box. This
means we are gcc4-compatible and MacOS/x86 ready. I used the latest from
CVS, and no patches to SDL were required.

SDL_mixer had a small compile issue in the native Mac midi code, but I
haven’t had a chance to look at it…it doesn’t appear to be x86
specific but rather a gcc4 thing. I didn’t try any other SDL libraries.

Obviously, the Altivec code isn’t used, and I don’t know if any MMX/SSE
codepaths were enabled, but it worked fine with the Mac port of Duke3D.

There aren’t speakers in the machine, so it’s possible there are byte
ordering issues in the sound system, but I doubt it.

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.

–ryan.

I spent some time in the lab Apple has set up at WWDC for people to
play around with their software on an Intel-based Mac platform.

SDL compiles and runs on the Intel MacOSX machines out of the box.
This means we are gcc4-compatible and MacOS/x86 ready. I used the
latest from CVS, and no patches to SDL were required.

SDL_mixer had a small compile issue in the native Mac midi code,
but I haven’t had a chance to look at it…it doesn’t appear to be
x86 specific but rather a gcc4 thing. I didn’t try any other SDL
libraries.

Obviously, the Altivec code isn’t used, and I don’t know if any MMX/
SSE codepaths were enabled, but it worked fine with the Mac port of
Duke3D.

There aren’t speakers in the machine, so it’s possible there are
byte ordering issues in the sound system, but I doubt it.

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.

On another note, SDL apps work fine under Rosetta. I tested Frozen
Bubble yesterday.

-bobOn Jun 7, 2005, at 9:14 PM, Ryan C. Gordon wrote:

Isn’t “-arch i386 -arch ppc” all that’s needed?

I dislike the ‘i386’ :wink: sounds so, soo ancient. but that’s what they
use.

Ryan C. Gordon kirjoitti 8.6.2005 kello 7.14:>

I spent some time in the lab Apple has set up at WWDC for people to
play around with their software on an Intel-based Mac platform.

SDL compiles and runs on the Intel MacOSX machines out of the box.
This means we are gcc4-compatible and MacOS/x86 ready. I used the
latest from CVS, and no patches to SDL were required.

SDL_mixer had a small compile issue in the native Mac midi code,
but I haven’t had a chance to look at it…it doesn’t appear to be
x86 specific but rather a gcc4 thing. I didn’t try any other SDL
libraries.

Obviously, the Altivec code isn’t used, and I don’t know if any MMX/
SSE codepaths were enabled, but it worked fine with the Mac port of
Duke3D.

There aren’t speakers in the machine, so it’s possible there are
byte ordering issues in the sound system, but I doubt it.

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.

–ryan.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Wait… isn’t Frozen Bubble written in Perl??On 6/8/05, Bob Ippolito wrote:

On another note, SDL apps work fine under Rosetta. I tested Frozen
Bubble yesterday.

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.

Hey Ryan (and others who were there too), sorry if it’s a bit offtopic
but I have to ask: does OSX/x86 run in native EM64T mode, or is it
plain old x86? Thanks.On 6/8/05, Ryan C. Gordon wrote:

I spent some time in the lab Apple has set up at WWDC for people to play
around with their software on an Intel-based Mac platform.

SDL compiles and runs on the Intel MacOSX machines out of the box. This
means we are gcc4-compatible and MacOS/x86 ready. I used the latest from
CVS, and no patches to SDL were required.

SDL_mixer had a small compile issue in the native Mac midi code, but I
haven’t had a chance to look at it…it doesn’t appear to be x86
specific but rather a gcc4 thing. I didn’t try any other SDL libraries.

Obviously, the Altivec code isn’t used, and I don’t know if any MMX/SSE
codepaths were enabled, but it worked fine with the Mac port of Duke3D.

There aren’t speakers in the machine, so it’s possible there are byte
ordering issues in the sound system, but I doubt it.

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.

–ryan.

On another note, SDL apps work fine under Rosetta. I tested Frozen
Bubble yesterday.

Wait… isn’t Frozen Bubble written in Perl??

Mostly. But it still uses SDL.

-bobOn Jun 8, 2005, at 12:31 AM, Simon Roby wrote:

On 6/8/05, Bob Ippolito <@Bob_Ippolito> wrote:

Great report from WWDC. Interesting stuff. Thanks alot.

ChrisOn 6/8/05, Ryan C. Gordon wrote:

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.


E-Mail: Chris Nystrom
Business: http://www.shaklee.net/austin
Blog: http://conversazione.blogspot.com/
AIM: nystromchris

One more interesting note: When compiling SDL against the 10.4
Universal SDK, Quickdraw functions are now marked as depreciated,
which means that the Quartz video files need to be updated to
entirely use CoreGraphics/Quartz. The invocation of any Quickdraw
calls will also immediately disable any potential benefits from Q2DE
(although I don’t expect those to be significant for SDL).

Is there interest on this list for upgrading/recreating the Xcode
project files?
Advantages:
Getting rid of some of the Shell Script build phases that can
now be done directly by Xcode’s build system
Begin producing universal SDL binaries by default for Deployment/
Release builds
Disadvantages:
This will require 10.4 with XCode 2.1 for development (the
project format has changed again)
This will require developers to install the 10.4 Universal SDK,
which is NOT installed by default by the Xcode 2.1 installer.

Will these second two points cause problems for mac-sdl developers?

Richard Schreyer

One more interesting note: When compiling SDL against the 10.4
Universal SDK, Quickdraw functions are now marked as depreciated,
which means that the Quartz video files need to be updated to
entirely use CoreGraphics/Quartz. The invocation of any Quickdraw
calls will also immediately disable any potential benefits from
Q2DE (although I don’t expect those to be significant for SDL).

Is there interest on this list for upgrading/recreating the Xcode
project files?
Advantages:
Getting rid of some of the Shell Script build phases that can
now be done directly by Xcode’s build system
Begin producing universal SDL binaries by default for
Deployment/Release builds
Disadvantages:
This will require 10.4 with XCode 2.1 for development (the
project format has changed again)
This will require developers to install the 10.4 Universal SDK,
which is NOT installed by default by the Xcode 2.1 installer.

Will these second two points cause problems for mac-sdl developers?

If most mac-sdl developers are using the pre-built frameworks, then
it’s a non-issue because only the maintainers need Xcode 2.1 and the
Universal SDK.

-bobOn Jun 17, 2005, at 5:01 PM, Richard Schreyer wrote:

'lo Richard,On 17/06/2005, Richard Schreyer, you wrote:

This will require 10.4 with XCode 2.1 for development (the  

project format has changed again)
This will require developers to install the 10.4 Universal SDK,
which is NOT installed by default by the Xcode 2.1 installer.

Will these second two points cause problems for mac-sdl developers?

As long as the configure & makefile still work under 10.3, I don’t care
(I don’t use Xcode). However it seems to me like a bad idea to force
developers into buying 10.4 etc. if they want/need to compile SDL
themselves.

Regards

Please remove “.ARGL.invalid” from my email when replying.
Incoming HTML mails are automatically deleted.