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
Re: Mac OS X Universal Binary Frameworks built?
Christian Walther
Guest
Post Posted: Mon Jan 09, 2006 9:44 am
Richard Schreyer wrote:
Quote:
- 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:

Quote:
From: Christian Walther <cwalther at gmx.ch>
Date: 5. Dezember 2005 9:36:59 Uhr GMT+01:00
To: "E. Wing" <ewmailing at gmail.com>
Cc: "Ryan C. Gordon" <icculus at icculus.org>
Subject: Re: SDL/OS X testing

Hello Eric

Quote:
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 Smile.

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.

Quote:
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


Quote:
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
Re: Mac OS X Universal Binary Frameworks built?
Andras Salamon
Guest
Post Posted: Mon Jan 09, 2006 2:07 pm
On Mon, Jan 09, 2006 at 10:44:25AM +0100, Christian Walther wrote:
Quote:
According to my experience, SDL requires 10.2
(http://article.gmane.org/gmane.comp.lib.sdl/24661/).

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 at dns.net
Re: Mac OS X Universal Binary Frameworks built?
Sam Lantinga
Guest
Post Posted: Thu Jan 19, 2006 9:52 am
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!

Quote:
On Mon, Jan 09, 2006 at 10:44:25AM +0100, Christian Walther wrote:
Quote:
According to my experience, SDL requires 10.2
(http://article.gmane.org/gmane.comp.lib.sdl/24661/).

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

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

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

Quote:
and later

Quote:
#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

Quote:
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.

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

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

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

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

Quote:
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.

Quote:
-- Andras Salamon andras at dns.net
Re: Mac OS X Universal Binary Frameworks built?
Ryan C. Gordon
Guest
Post Posted: Sun Jan 22, 2006 8:33 am
Sam Lantinga wrote:
Quote:
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?

Will do.
https://bugzilla.libsdl.org/show_bug.cgi?id=64

--ryan.