Mac OS X Universal Binaries and Xcode Projects ready for testing

SDL Development
1

Updated Xcode projects for Universal Binaries have been committed to
CVS and initial binary packages (.dmg) are available here:
http://www.libsdl.org/cvs/

Projects included are SDL, SDL_image, SDL_mixer, SDL_ttf, and smpeg.
(Static libraries updated for libpng, libjpeg, libfreetype, libogg,
libvorbis).

The SDL and smpeg binaries were built against the CVS version pulled
maybe a month ago so they may be a little behind.

There are a huge list of changes made to the projects, many things not
directly related to Universal Binaries so testing is needed.

I do not have an Intel Mac to test on so I have no idea if this stuff
actually works. However, Christian Walther has been a big help in
testing 10.2.8 and 10.3.9 so I’m fairly confident we got the build
settings correct for at least PPC.

I have attempted to document the important things for producing these
Universal Binaries. Documentation is somewhat scattered through out
everything, but there is a big centralized piece of documentation in
the UniversalBinaryNotes.rtf in the SDL.dmg.

As far as Universal Binaries are concerned, the big things were:

  • Build with gcc 3.3 on PPC, 4.0 on Intel.
  • We couldn’t get any of the MMX/SSE code to compile/link (SDL and smpeg).
  • All 3rd party dependencies had to be rebuilt as Universal

There were also a bunch of non-Universal things that have been updated:

  • I converted the SDL-satellites to create .dmg’s instead of .pkg installers
  • Updated all 3rd party static libraries with current versions. (I
    think libpng was the most dramatic going from 1.0.? to 1.2.8 with API
    breakage. I haven’t found any problems so far in doing this.)
  • Changed some compiler optimization settings
  • Finally updated the exports list for SDL_mixer
  • Tried to include a static smpeg in SDL_mixer (multiple build
    variants in Xcode project now)
  • Enabled Altivec in SDL (we forgot to add the flags to Xcode last time)
  • More documentation

Since so many things have changed, there might be new problems
introduced. The big issue I’ve found so far is with SDL_mixer. As I
mentioned in other threads, Mikmod and SMPEG continue to cause
problems. SMPEG is currently compiled into the binary in the above
link, but produces runtime assertion errors for me.

Areas that need testing/focus/fixing:

  • Test to make sure binaries actually work (especially on x86).
  • Test to make sure Altivec is actually working on PowerPC.
  • Test to make sure things work on older versions of OS X and things
    can be built on those systems linking against our Universal
    frameworks.
  • Test to make sure the Xcode projects actually work on other systems
    (make sure absolute paths were not accidentally set).
  • Fix MMX/SSE optimizations so they can be compiled in for SDL and smpeg
  • Fix Mikmod for SDL_mixer
  • Fix smpeg/mp3 playback for SDL_mixer

Also, there is a longer term needed task of figuring out what to do
with all the “deprecated API” warnings we get now under Tiger. It is
likely that using deprecated APIs will cause us to fall off optimized
code paths in the future.

There’s probably a bunch of other stuff I’m forgetting. There really
were hundreds of little things I mucked with so it’s hard to remember
them all.

Again, please read over the UniversalBinaryNotes.rtf in the SDL.dmg.
This will hopefully explain a great many things that may seem strange
otherwise.

If you have any questions, feel free to ask.

Thanks,
Eric

2

Well, first positive piece of feedback is that these fixed the SDL_image
crash on 10.3.9 PPC. Excellent work!

cheers,
a1On 2/2/06, E. Wing wrote:

Updated Xcode projects for Universal Binaries have been committed to
CVS and initial binary packages (.dmg) are available here:
http://www.libsdl.org/cvs/

3

E. Wing wrote:

Areas that need testing/focus/fixing:

  • Test to make sure binaries actually work (especially on x86).
  • Test to make sure Altivec is actually working on PowerPC.
    I’ve no idea how to check if it’s actually taking the Altivec code path
    (I checked if the Altivec unit can be disabled in the Processor
    preference pane, so that I could compare the performance, but it doesn’t
    seem so), but the frameworks seem to work on both my G3 and my G4. My
    application only uses straight 24/32 bit RGB(A) blitting though, none of
    the more exotic cases.
  • Test to make sure things work on older versions of OS X and things
    can be built on those systems linking against our Universal
    frameworks.
    Seems to work on 10.2 and 10.3. Linking against the frameworks with
    Xcode 1.5 (GCC 3.3) on 10.3.9 works fine. I don’t have developer tools
    for 10.2 at hand right now, but in the unlikely case that a. anyone is
    still developing on 10.2 and b. it doesn’t work, they will hopefully
    come here and complain.
  • Test to make sure the Xcode projects actually work on other systems
    (make sure absolute paths were not accidentally set).
    Will eventually do that once I’m on Tiger/Xcode 2.2 (should be REAL SOON
    :slight_smile: ). (I suppose you didn’t update the Xcode 1.5 projects?)

One thing that I noticed when I tried to compile the programs in the
test directory: the SDL framework doesn’t include SDL_cpuinfo.h, which
is used by testcpuinfo.c (the file is marked as private in the Xcode
project and therefore isn’t copied to the framework). Is that intentional?

-Christian

4

Sorry for the delay. I’ve been swamped.

-8859-1; format=flowed

E. Wing wrote:

Areas that need testing/focus/fixing:

  • Test to make sure binaries actually work (especially on x86).
  • Test to make sure Altivec is actually working on PowerPC.
    I’ve no idea how to check if it’s actually taking the Altivec code path
    (I checked if the Altivec unit can be disabled in the Processor
    preference pane, so that I could compare the performance, but it doesn’t
    seem so), but the frameworks seem to work on both my G3 and my G4. My
    application only uses straight 24/32 bit RGB(A) blitting though, none of
    the more exotic cases.

I forgot to enable the Altivec flags in the 1.2.9 framework, so
comparing performance to the old framework might be a giveaway. But
then again, I might be missing a flag this time too or Altivec doesn’t
help in these cases. I did try comparing the prepackaged version of
Blob Wars on an old G4 Cube (runs kind of slow) and then swapping the
framework. It felt a little faster, but I didn’t have a fps counter so
my analysis is all based on perception.

  • Test to make sure things work on older versions of OS X and things
    can be built on those systems linking against our Universal
    frameworks.
    Seems to work on 10.2 and 10.3. Linking against the frameworks with
    Xcode 1.5 (GCC 3.3) on 10.3.9 works fine. I don’t have developer tools
    for 10.2 at hand right now, but in the unlikely case that a. anyone is
    still developing on 10.2 and b. it doesn’t work, they will hopefully
    come here and complain.

Sounds good.

  • Test to make sure the Xcode projects actually work on other systems
    (make sure absolute paths were not accidentally set).
    Will eventually do that once I’m on Tiger/Xcode 2.2 (should be REAL SOON
    :slight_smile: ). (I suppose you didn’t update the Xcode 1.5 projects?)

No, I only run Tiger now so I have no way of altering the older
Xcode/Project Builder projects. Moving forward, it’s not so important
since only the Tiger/Xcode 2.2+ projects will be able to produce
Universal Binaries that work. If you want to fix the 1.5 projects, be
my guest, but I don’t think it’s terribly important. I think the big
change is the files in the CD-ROM section have been rewritten to
remove all the C++ code so the filenames have changed. Oh, and you
might want to enable Altivec. But I thought I read that Sam is moving
all the files around. So maybe this is going a real pain.

One thing that I noticed when I tried to compile the programs in the
test directory: the SDL framework doesn’t include SDL_cpuinfo.h, which
is used by testcpuinfo.c (the file is marked as private in the Xcode
project and therefore isn’t copied to the framework). Is that intentional?

No, this is a bug. Good catch. The exported public headers are all
messed up. I’ve cleaned this up and need to resubmit. (But I need to
look into if Sam moved everything and if so, resync when things get
settled.)

Thanks,
Eric> Date: Sat, 04 Feb 2006 16:24:51 +0100

From: Christian Walther

5

Hello !

Does the latest CVS version
works on your system, using
the Unix way ?

CU

6

Hello !

Does the latest CVS version
works on your system, using
the Unix way ?
CU

Sorry, I haven’t tried it. I still haven’t sync’d up to the current
CVS and I almost never touch the autoconf system. Somebody else will
have to field this one.

-Eric