Mac OS X Universal Binary Frameworks built?

Steven_Saunders · January 6, 2006, 6:07am

Hi All,

Just thought I’d check before trying to do it myself: Has anyone out
there built the SDL 1.2.9 and SDL_mixer 1.2.6 Mac OS X frameworks
(not .a’s) in universal binary (ppc and i386) form yet?

If so, can someone point me to where I can download them?

Thanks.__
Steve

Send instant messages to your online friends http://au.messenger.yahoo.com

Richard_Schreyer · January 6, 2006, 5:42pm

I have built Universal binaries SDL 1.2.9 (out of CVS) and SDL_image
1.2.4 for use with OpenGL. They work just fine. I haven’t used any
2D drawing, so I do not know if the SSE blitters are active. I also
haven’t tried SDL_mixer.

I also spent quite a bit of time cleaning the cruft out of the
project files left over by several previous projectbuilder/xcode
upgrades. The way I have it set up, the debug configuration builds
for the current target while the release configuration builds for ppc/
i386. SDL_image also required compiling UB versions of libpng and
libjpeg.

I am not prepared to submit these back yet because:

The install targets (specifically the run_scripts build phases) are
basically flawed. I haven’t spent any time trying to update these.
Xcode’s existing infrastructure is perfectly capable of dealing with
the install task on it’s own, so ideally we would dump the custom
shell scripts entirely, and just use what is already provided to us.
10.1/10.2 support. As my project files are set up, the minimum
target that SDL is compiled for is 10.3.9, and requires the 10.4.0
Universal SDK. Xcode 2.2 does contain the ability to compile against
different SDKs depending on the target architecture, so I need to
investigate this. I also don’t have any 10.1 or 10.2 systems to test
against. (What is the earliest version that SDL needs to support at
runtime?).

I also haven’t come up with a great solution to include paths in
xcode projects (since other users will have these installed at
different locations, or want to install their headers to different
locations). This is the ugly side of using #include “foo” where we
really should be using #include <SDL/foo> (can this please change in
SDL 1.3?).

I assume there is some interest in trying to address these issues and
get SDL building Universal directly out of CVS? How much of this has
already been done by others but not checked in?

RichardOn Jan 5, 2006, at 10:07 PM, Steven Saunders wrote:

Hi All,

Just thought I’d check before trying to do it myself: Has anyone out
there built the SDL 1.2.9 and SDL_mixer 1.2.6 Mac OS X frameworks
(not .a’s) in universal binary (ppc and i386) form yet?

If so, can someone point me to where I can download them?

Thanks.
__
Steve

Send instant messages to your online friends http://
au.messenger.yahoo.com

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

Christian_Walther · January 9, 2006, 9:44am

Richard Schreyer wrote:

10.1/10.2 support. As my project files are set up, the minimum
target that SDL is compiled for is 10.3.9, and requires the 10.4.0
Universal SDK. Xcode 2.2 does contain the ability to compile against
different SDKs depending on the target architecture, so I need to
investigate this. I also don’t have any 10.1 or 10.2 systems to test
against. (What is the earliest version that SDL needs to support at
runtime?).

According to my experience, SDL requires 10.2
(http://article.gmane.org/gmane.comp.lib.sdl/24661/). I once did some
tests using Xcode 2.2 and here’s what I wrote about it:> From: Christian Walther <@Christian_Walther>

Date: 5. Dezember 2005 9:36:59 Uhr GMT+01:00
To: “E. Wing”
Cc: “Ryan C. Gordon”
Subject: Re: SDL/OS X testing

Hello Eric

By the way, since you guys will be testing on legacy systems, I was
wondering if you could try building the framework with gcc 4.0.1 from
Xcode 2.2. (Perhaps even turn on the Universal Binary options.)

I tried a few things today, and, in a nutshell, I haven’t been able
to compile an SDL framework that works on 10.2.8 using gcc 4.0.1 on
10.4.3 - but that may just be because it was the first time I used
Xcode 2.x :).

Here’s what I did in detail:

Building the “Deployment” configuration of the “Framework” target
of “SDL.xcodeproj” as-is doesn’t work because it still contains
references to the old C++ files in src/cdrom/macosx/. Once these are
changed to the new C files, the build succeeds (with a lot of
warnings though).

The SDL framework gotten that way does not work on 10.2.8 because
of “Undefined symbols: SDL undefined reference to _fprintf$LDBL128
expected to be defined in /usr/lib/libSystem.B.dylib”. That’s because
it’s linked against libSystem.B.dylib current version 88.1.2, while
10.2.8 only has 63.0.0.

Rebuilding after choosing “Cross-Develop Using Target SDK: Mac OS X
10.2.8” in the project info window fails because MacOSX10.2.8.sdk
doesn’t contain the X11 headers (the 10.3.9 and 10.4u SDKs do).
Adding /usr/X11R6/include to the “Header Search Paths” in the target
info window remedies that.

The result for some reason is a framework that is still linked
against libSystem.B.dylib 88.1.2 and therefore doesn’t work on 10.2.8
(with the same missing symbol as before), even though
MacOSX10.2.8.sdk contains libSystem.B.dylib 63.0.0. That looks like a
bug to me, any ideas?

Building with a setting GCC_VERSION_ppc = 3.3 added to the project
build settings yields a framework that is properly linked against
libSystem.B.dylib 63.0.0 and works on 10.2.8.

Using GCC 3.3 for the PPC part, it’s also possible to build a
universal binary that works on 10.2.8 (PPC) (no idea whether it works
on x86): Choose “Cross-Develop Using Target SDK: Mac OS X 10.4
(Universal)”, then add GCC_VERSION_ppc = 3.3,
MACOSX_DEPLOYMENT_TARGET_ppc = 10.2, SDKROOT_ppc =
/Developer/SDKs/MacOSX10.2.8.sdk to the project build settings.

So I would like to know if these frameworks will now actually run on
something like Jaguar and if we need to use the -static-libgcc flag
or not.

-static-libgcc seems to be the default. There is no libgcc_s in the
output of otool -L both with and without it, while it is there if
-shared-libgcc is specified.

Hope that helps

-Christian

I also haven’t come up with a great solution to include paths in xcode
projects (since other users will have these installed at different
locations, or want to install their headers to different locations).

I’m not sure about Xcode 2 (still haven’t upgraded my main machine to
Tiger), but in Xcode 1.5 there’s a “Header Search Paths” setting in the
target build settings where you can insert
"/Library/Frameworks/SDL.framework/Headers
$(HOME)/Library/Frameworks/SDL.framework/Headers
$(HOME)/Library/Frameworks/SDL_image.framework/Headers". I think that
covers the usual locations.

-Christian

Andras_Salamon · January 9, 2006, 2:07pm

Does this mean we can get rid of the ancient, Mac-specific, pre-10.1
hacks regarding semaphores and threading?

For instance, in src/thread/linux/SDL_syssem.c there is

#ifdef MACOSX
#define USE_NAMED_SEMAPHORES
/* Broken sem_getvalue() in MacOS X Public Beta /
#define BROKEN_SEMGETVALUE
#endif / MACOSX */

and later

#ifdef BROKEN_SEMGETVALUE
/* This is a little hack for MacOS X -
It’s not thread-safe, but it’s better than nothing
*/
int sem_value;
#endif

Perhaps someone knows why the BROKEN_SEMGETVALUE hack was introduced
(CVS history for this file only seems to start in 2001). Is there test
code that demonstrates a problem, or is there some other compelling reason
to mess with semaphores in the presence of threading on Mac OS X? I don’t
think SDL should be tiptoeing around bugs in a 5 year old beta this way.

Further, in src/thread/linux/SDL_systhread.c appears, twice:

#if !defined(MACOSX) /* pthread_sigmask seems to be missing on MacOS X? */

while my 10.3.9 system has (not sure when it was introduced):

/usr/include/pthread.h:int pthread_sigmask(int, const sigset_t *,
sigset_t *);

Building with these hacks removed results in code that seems less
prone to weird asynchronous behaviour in network code that uses the SDL
synchronization primitives, at least in my experience.

– Andras Salamon @Andras_SalamonOn Mon, Jan 09, 2006 at 10:44:25AM +0100, Christian Walther wrote:

According to my experience, SDL requires 10.2
(http://article.gmane.org/gmane.comp.lib.sdl/24661/).

Eric_Wing · January 9, 2006, 8:08pm

I have built Universal binaries SDL 1.2.9 (out of CVS) and SDL_image
1.2.4 for use with OpenGL.

10.1/10.2 support. As my project files are set up, the minimum
target that SDL is compiled for is 10.3.9, and requires the 10.4.0
Universal SDK. Xcode 2.2 does contain the ability to compile against
different SDKs depending on the target architecture, so I need to
investigate this. I also don’t have any 10.1 or 10.2 systems to test
against. (What is the earliest version that SDL needs to support at
runtime?).

Yes, a few of us have been working out the details for this. I think
semi-officially, we support from 10.2. Using the standard options for
the Universal SDK has been introducing additional dependencies which
cause problems for anything less than 10.3.9. There was a problem with
a new dependency with libgcc_s which Apple has fixed in Xcode 2.2/gcc
4.0.1, but there is still a problem with an undefined symbol for
_fprintf$LDBL128 expected to be defined in /usr/lib/libSystem.B.dylib.
We have discovered how to set Xcode to use different versions of gcc
on a per-architecture basis, but I think the libSystem incompatible
version issue is still getting in the way so we are still
investigating the best way to get around this.

I also spent quite a bit of time cleaning the cruft out of the
project files left over by several previous projectbuilder/xcode
upgrades. The way I have it set up, the debug configuration builds
for the current target while the release configuration builds for ppc/
i386. SDL_image also required compiling UB versions of libpng and
libjpeg.

Yes, there is a lot of stuff that needs to be cleaned up. It’s been on
my todo list. The main SDL project already has undergone some cleanup
which should already be in the 1.2.9 dist, but I haven’t gone through
the SDL-satellite projects yet.

I am not prepared to submit these back yet because:

The install targets (specifically the run_scripts build phases) are
basically flawed. I haven’t spent any time trying to update these.

I’m not sure what you mean by the install targets being “flawed”. But
yes, the shell script phases need to be cleaned up. As I said, the
main SDL project has already undergone some cleanup, but a shell
script phase still exists because we use it to create a package for
distribution. But it is much simpler than before. Among the changes
include, no more spilting a framework into headers and runtime, a .dmg
based package instead of an .pkg installer for privileges concerns,
and a better separation of the core SDL framework and optional
developer stuff.

Xcode’s existing infrastructure is perfectly capable of dealing with
the install task on it’s own, so ideally we would dump the custom
shell scripts entirely, and just use what is already provided to us.

If you are expecting to use Xcode to actually copy the framework to
/Library/Frameworks using their built-in functionality, it’s probably
not going to happen/work because we set the install_name to
@executable_path/…/Frameworks which I believe Xcode uses to decide
where to copy things. Furthermore, as I said, we use the script phase
to build us packages for distribution. We don’t require or intend
everybody to compile SDL from source just to install it.

I also haven’t come up with a great solution to include paths in
xcode projects (since other users will have these installed at
different locations, or want to install their headers to different
locations).

In the Xcode field “Header Search Paths”, you can specify multiple
locations just by listing them (separated by spaces). I think in our
project templates, we already set the paths to
$(HOME)/Library/Frameworks/SDL.framework/Headers
/Library/Frameworks/SDL.framework/Headers
Add more as needed.

This is the ugly side of using #include “foo” where we
really should be using #include <SDL/foo> (can this please change in
SDL 1.3?).

Unforunately, moving to #include <SDL/foo> will never likely work
correctly in a portable sense. Already, not all platforms put their
headers in a directory called SDL/. (For example, FreeBSD Ports puts
theirs in SDL11/.) Furthermore, with Mac frameworks, this will break
down for the SDL-satellite projects. Many distributions put the
SDL_image.h, SDL_mixer.h, etc headers in SDL/, but they are separate
libraries and hence separate frameworks under the Mac. All OS X
framework code would require the usage: #include
<SDL_mixer/SDL_mixer.h> and <SDL_image/SDL_image.h>. Chances are that
most other distros (including OS X based Fink and DarwinPorts) won’t
follow this convention. #include “foo” is really the only portable
option unless SDL takes it on themselves to create and enforce
packaging requirements. But I don’t think that’s going to happen.

-Eric> From: Richard Schreyer <rws_list at girr.org>

icculus · January 10, 2006, 2:12am

Yes, a few of us have been working out the details for this. I think
semi-officially, we support from 10.2. Using the standard options for

Not semi-officially: if I tried to ship a game that didn’t support 10.2,
my publisher would refuse to ship until I corrected it.

It seems that 10.2 is the minimum acceptable platform in terms of
marketing, at least at this point. I’ve never had anyone complain that a
title didn’t work on 10.1.

I’d actually like it to work back to 10.0, but not if it requires lots
of work or ugly changes…the public beta, though? That crap can go.

–ryan.

slouken · January 19, 2006, 9:52am

These were for bugs in the public beta and MacOS X 10.0 (10.1?)
Ryan, can you confirm that these are not problems in 10.2 and then nuke them?

Thanks!> On Mon, Jan 09, 2006 at 10:44:25AM +0100, Christian Walther wrote: