SDL under Mac OS X

Hello,

I want to build my game for OS X. SDL shouldn’t be statically linked
because my program isn’t GPL. Should I use the “framework” or the
UNIX-style shared lib system ?

I’d like to be able to keep SDL in my game’s directory, too.

I googled and looked at the os x faq on libsdl.org but didn’t find the
answer.

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

You can build an application with the shared lib, but that would
probably involve installing the lib into one of the standard system
paths, which would mean you need an installer (not good on OS X).

Go for the framework. In XCode, create a ‘Copy Files’ build phase that
will copy SDL.framework (and SDL_image.framework, and whatever else),
into the Frameworks folder inside the bundle.

Richard Schreyer

Olivier Fabre wrote:> Hello,

I want to build my game for OS X. SDL shouldn’t be statically linked
because my program isn’t GPL. Should I use the “framework” or the
UNIX-style shared lib system ?

I’d like to be able to keep SDL in my game’s directory, too.

I googled and looked at the os x faq on libsdl.org but didn’t find the
answer.

Thanks,

Olivier Fabre wrote:

Hello,

I want to build my game for OS X. SDL shouldn’t be statically linked
because my program isn’t GPL. Should I use the “framework” or the
UNIX-style shared lib system ?

I’d like to be able to keep SDL in my game’s directory, too.

I googled and looked at the os x faq on libsdl.org but didn’t find the
answer.

Thanks,

It also works fine to include the shared library in the Frameworks
subtree of the bundle.

Matt

Olivier Fabre wrote:

Hello,

I want to build my game for OS X. SDL shouldn’t be statically linked
because my program isn’t GPL. Should I use the “framework” or the
UNIX-style shared lib system ?

I’d like to be able to keep SDL in my game’s directory, too.

I googled and looked at the os x faq on libsdl.org but didn’t find the
answer.

Thanks,

It also works fine to include the shared library in the Frameworks
subtree of the bundle.

Assuming it was linked as @executable_path relative, of course. The
"developer" framework available from libsdl.org is already linked in
this manner so it’s less of a hassle.

-bobOn Jan 15, 2005, at 23:28, Matthew Cox wrote:

Bob Ippolito wrote:> On Jan 15, 2005, at 23:28, Matthew Cox wrote:

Olivier Fabre wrote:

Hello,

I want to build my game for OS X. SDL shouldn’t be statically linked
because my program isn’t GPL. Should I use the “framework” or the
UNIX-style shared lib system ?

I’d like to be able to keep SDL in my game’s directory, too.

I googled and looked at the os x faq on libsdl.org but didn’t find the
answer.

Thanks,

It also works fine to include the shared library in the Frameworks
subtree of the bundle.

Assuming it was linked as @executable_path relative, of course. The
"developer" framework available from libsdl.org is already linked in
this manner so it’s less of a hassle.

Sure, I frameworks also have to be linked that way. You can either try
and see if you can bodge it with the install_name_tool, or you can just
build it from scratch passing that as a linker argument.

I would tend to recommend bundling the library instead of the framework.
It seems wasteful to distribute the headers and versioning stuff that a
framework entails. No reason you couldn’t remove the headers and all
that, it’s just that at that point why bother with the framework shells?
Just my 20 millidollars.

Matt

Bob Ippolito wrote:

Olivier Fabre wrote:

I want to build my game for OS X. SDL shouldn’t be statically linked
because my program isn’t GPL. Should I use the “framework” or the
UNIX-style shared lib system ?

I’d like to be able to keep SDL in my game’s directory, too.

I googled and looked at the os x faq on libsdl.org but didn’t find
the
answer.

It also works fine to include the shared library in the Frameworks
subtree of the bundle.

Assuming it was linked as @executable_path relative, of course. The
"developer" framework available from libsdl.org is already linked in
this manner so it’s less of a hassle.

Sure, I frameworks also have to be linked that way. You can either try
and see if you can bodge it with the install_name_tool, or you can
just build it from scratch passing that as a linker argument.

I would tend to recommend bundling the library instead of the
framework. It seems wasteful to distribute the headers and versioning
stuff that a framework entails. No reason you couldn’t remove the
headers and all that, it’s just that at that point why bother with the
framework shells? Just my 20 millidollars.

Well, as I said, the prebuilt framework in the developer package is
already linked as such. You have to build a custom library in order to
get that behavior. The “versioning stuff” is a couple extra
directories and a few symlinks, so that’s really a non-issue.
Including the headers by default isn’t something to worry about either,
they’re not terribly big, they compress awfully well, and they’re
trivial to strip if you really want to take them out.

Frameworks have additional advantages, but SDL doesn’t use any of them.
For example, SDL could include resources (nibs or plugins for example)
and reference them relatively to the framework. You can’t do that
(usefully) with a bare dylib.

I recommend frameworks because it’s the easiest way to do it correctly.

-bobOn Jan 16, 2005, at 2:27, Matthew Cox wrote:

On Jan 15, 2005, at 23:28, Matthew Cox wrote:

I want to build my game for OS X. SDL shouldn’t be statically linked
because my program isn’t GPL. Should I use the “framework” or the
UNIX-style shared lib system ?

I’d like to be able to keep SDL in my game’s directory, too.

I googled and looked at the os x faq on libsdl.org but didn’t find the
answer.

Here’s how I did it for ut2004 (which may not be the best way, but it
was the cleanest in the long run, in my opinion):

Build SDL “the unix way”…unpack the source, and from a Terminal:

cd /where/i/unpacked/SDL-1.2.8
./configure
cd src
make

Let the thing compile for awhile. When it finishes, one of the last
things in there should be the link command line…it starts something
like this…

gcc -dynamiclib  -o .libs/libSDL-1.2.0.7.1.dylib  .libs/SDL.o

…and runs for 35 lines or so.

Cut and paste that command, making a small change:

Find:

  -install_name  /usr/local/lib/libSDL-1.2.0.dylib

Change that to:

  -install_name @executable_path/libSDL-1.2.0.dylib

Take the library (.libs/libSDL-1.2.0.7.1.dylib, on my system) and put it
into your project. Link against that file. Now the program when run will
look for “libSDL-1.2.0.dylib” in the same directory as the program.

This is a pain to set up, but is dead simple thereafter, in terms of
packaging and distribution. Real Mac programmers are probably cringing
right now and can offer a better solution, but this worked great for me.

–ryan.

I want to build my game for OS X. SDL shouldn’t be statically linked
because my program isn’t GPL. Should I use the “framework” or the
UNIX-style shared lib system ?
I’d like to be able to keep SDL in my game’s directory, too.
I googled and looked at the os x faq on libsdl.org but didn’t find the
answer.

Here’s how I did it for ut2004 (which may not be the best way, but it
was the cleanest in the long run, in my opinion):

Build SDL “the unix way”…unpack the source, and from a Terminal:

cd /where/i/unpacked/SDL-1.2.8
./configure
cd src
make

Let the thing compile for awhile. When it finishes, one of the last
things in there should be the link command line…it starts something
like this…

gcc -dynamiclib -o .libs/libSDL-1.2.0.7.1.dylib .libs/SDL.o

…and runs for 35 lines or so.

Cut and paste that command, making a small change:

Find:

 -install_name  /usr/local/lib/libSDL-1.2.0.dylib

Change that to:

 -install_name @executable_path/libSDL-1.2.0.dylib

Take the library (.libs/libSDL-1.2.0.7.1.dylib, on my system) and put
it into your project. Link against that file. Now the program when run
will look for “libSDL-1.2.0.dylib” in the same directory as the
program.

This is a pain to set up, but is dead simple thereafter, in terms of
packaging and distribution. Real Mac programmers are probably cringing
right now and can offer a better solution, but this worked great for
me.

That’s close enough to the right solution. You should probably be
using a different path as per Apple’s recommendation
(@executable_path/…/Frameworks/libSDL-1.2.0.dylib), but there is
nothing technically wrong with yours. Additionally, rather than
cutting and pasting 35 lines of junk, you could use
install_name_tool(1) as a post-process on this dylib (works about 99.5%
of the time, in some edge cases install_name_tool will fail, but it
will tell you it failed), or edit the configure script and/or Makefile
to do this for you.

The Xcode project that SDL comes with will build a framework of this
style even easier. Basically, rip open the tarball, go to the
directory it creates, and type “xcodebuild”. It should be
preconfigured to build a development-style framework. I’m not sure how
people think the library solution is easier (or why you feel the need
to build it yourself, unless you’re patching it, but then you have LGPL
issues), but whatever floats your boat.

-bobOn Jan 16, 2005, at 14:21, Ryan C. Gordon wrote:

Bob Ippolito wrote:

I’m not sure how people think the library solution is easier (or why
you feel the need to build it yourself, unless you’re patching it, but
then you have LGPL issues), but whatever floats your boat.

I think that’s precisely it. The people advocating the dylib approach
tend to be people coming from a traditional unix environment. It sounds
like the original poster was porting from Linux, so this is probably
what will make more sense to him.

I’m not sure what optimizations are applied to the dylib (-Os/n?, G3,
G4, G5?), which is another reason to build yourself.

Then of course there’s the unix mindset of not really trusting anything
you haven’t compiled yourself (hey, that’s why I was a Gentoo user pre-OS X)

Matt

Bob Ippolito wrote:

I’m not sure how people think the library solution is easier (or why
you feel the need to build it yourself, unless you’re patching it,
but then you have LGPL issues), but whatever floats your boat.

I think that’s precisely it. The people advocating the dylib approach
tend to be people coming from a traditional unix environment. It
sounds like the original poster was porting from Linux, so this is
probably what will make more sense to him.

I’m not sure what optimizations are applied to the dylib (-Os/n?, G3,
G4, G5?), which is another reason to build yourself.

Not a good one.

You can’t really distribute software that doesn’t work on a G3, so the
default optimizations used by the Xcode project are fine. When the
Altivec patches make it in, they will be used conditionally at runtime
depending on the CPU. Processor specific compile time optimization
flags are simply not appropriate when you’re distributing compiled
software for a heterogeneous environment. In my experience, even if
you do have the “luxury” of using them, they also do not have much of
an impact on performance anyway. -fast can get you a few percent in
some cases, but then your application doesn’t work on anything but the
G5.

If you’re compiling SDL merely to use software on your own computer,
then I envy the amount of spare time you have and wonder why you’d want
to spend it tweaking compiler optimization flags for almost no
measurable return.

Then of course there’s the unix mindset of not really trusting
anything you haven’t compiled yourself (hey, that’s why I was a Gentoo
user pre-OS X)

Where “compiled yourself” means “emerge compiled it for me with
whatever options the maintainer chose to use”? :slight_smile:

-bobOn Jan 17, 2005, at 16:29, Matthew Cox wrote:

Bob Ippolito wrote:

You can’t really distribute software that doesn’t work on a G3, so the
default optimizations used by the Xcode project are fine. When the
Altivec patches make it in, they will be used conditionally at runtime
depending on the CPU. Processor specific compile time optimization
flags are simply not appropriate when you’re distributing compiled
software for a heterogeneous environment. In my experience, even if
you do have the “luxury” of using them, they also do not have much of
an impact on performance anyway. -fast can get you a few percent in
some cases, but then your application doesn’t work on anything but the G5.

That wasn’t my point at all. There’s a difference between optimizing for
a processor, and compiling only for that processor. You can optimize the
scheduling and other such things for a specific CPU (Xcode can do this
for you, I believe.) Depending on your software project, supporting a G3
may be a total non-starter if the CPU reqs are above a certain level. So
scheduling for a G4 (to get optimal performance on the low end) at the
expense of small inefficiencies on the higher end machines (which won’t
be noticed) makes sense.

Furthermore, -Os can be one of the best optimizations you can apply. The
more you can fit into your i-cache the better. Apple recommends all
shipping code be -Os. So unless you know for certain that these binaries
are built optimized for size, you shouldn’t ship them.

Then of course there’s the unix mindset of not really trusting
anything you haven’t compiled yourself (hey, that’s why I was a
Gentoo user pre-OS X)

Where “compiled yourself” means “emerge compiled it for me with
whatever options the maintainer chose to use”? :slight_smile:

Touch?, 'cept for my makeflags :stuck_out_tongue:

Matt

Hello again,

Thanks a lot to everyone who answered! Your mails gave me hints about
what to look for… Unfortunately, as I don’t know anything about linux
shared libraries, nor about OSX programming, I needed practical
instructions.

Ryan’s method seemed to be what I needed, but unfortunately I couldn’t
make it work because libtool deletes the object files and so I couldn’t
use them again to rebuild the lib with the -install-name parameter. I
tried (first) hacking the Makefile to change the install path there,
but after a few hours (finding that it was libtool that was used to
link the lib, trying to understand its doc…), I couldn’t make it
work. I also tried modifying the libtool script with no luck.

Then I tried the “install_name_tool” way. I googled some more using
magical keywords like “executable_path” and “install_name_tool” and
finally found the answer… in the McAfee support forum!

http://forums.mcafeehelp.com/viewtopic.php?t=6318

Basically, after the lib is compiled, you have to type:

install_name_tool -id @executable_path/libSDL.dylib libSDL.dylib

(I renamed libSDL-1.2.0.7.1.dylib to libSDL.dylib in order to make room
for “@executable_path” since it is longer than “/usr/local/lib”. It’s
also easier to type :wink: )

And then put this lib into the executable’s directory and link against
it. (done by adding “-L.” in front of “-L/usr/local/lib” in the linker
flags.)

The otool tool can be used to check that the exe is linked against the
correct lib:

otool -L testprogram

I think that’s precisely it. The people advocating the dylib approach
tend to be people coming from a traditional unix environment. It
sounds like the original poster was porting from Linux, so this is
probably what will make more sense to him.

I fact, not at all. I originally wrote my game on Amiga (using the
AmigaOS API and MiniGL), then ported it to SDL/Win32, and now I’m
porting it to Mac OS X.

Then of course there’s the unix mindset of not really trusting
anything you haven’t compiled yourself

I would have been happier with a pre-built SDL for OS X, but I couldn’t
find one on www.libsdl.org’s downloads page. I don’t remember exactly,
but I think I downloaded the framework thing, and then its installer
told me it had installed everything I didn’t want and I had to use the
source distro to get what I wanted. At least, that’s what I understood
:].

Now it’s time to build zlib, libpng, SDL_image and SDL_mixer, I guess
:-}.

Thanks,On 17/01/2005, Matthew Cox, you wrote:

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

Then of course there’s the unix mindset of not really trusting
anything you haven’t compiled yourself

I would have been happier with a pre-built SDL for OS X, but I couldn’t
find one on www.libsdl.org’s downloads page. I don’t remember exactly,
but I think I downloaded the framework thing, and then its installer
told me it had installed everything I didn’t want and I had to use the
source distro to get what I wanted. At least, that’s what I understood
:].

Well, you’re mistaken… The SDL framework isn’t missing anything as
far as I can tell. I’ve been using them for quite some time.

Now it’s time to build zlib, libpng, SDL_image and SDL_mixer, I guess
:-}.

zlib ships with the OS, SDL_image and SDL_mixer should also be
available as precompiled frameworks from their respective download
pages.

-bobOn Jan 18, 2005, at 4:07, Olivier Fabre wrote:

Well, you’re mistaken… The SDL framework isn’t missing anything as
far as I can tell. I’ve been using them for quite some time.

After these two days spent looking for information and trying various
things, I would probably understand better what happens when the
framework is installed, I guess.

zlib ships with the OS, SDL_image and SDL_mixer should also be
available as precompiled frameworks from their respective download
pages.

Thanks, I’ll have another look when the site works again!On 18/01/2005, Bob Ippolito, you wrote:


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

but I think I downloaded the framework thing, and then its installer
told me it had installed everything I didn’t want and I had to use
the
source distro to get what I wanted. At least, that’s what I
understood :]

Well, you’re mistaken… The SDL framework isn’t missing anything as
far as I can tell. I’ve been using them for quite some time.

Looks like I wasn’t dreaming. Here is what the SDL 1.2.8 developer
package for Mac OS X says after install:

What was installed and where:
Project Stationary in /Developer/ProjectBuilder Extras
HTML documentation in /Developer/Documentation/SDL
This README in your home directory.
Package receipt in /Library/Receipts/SDL-devel.pkg

What was not installed (Available in the SDL source code):
- SDL framework.
- SDL library source code and Framework Projects.
- configure/make support (available with source code).

zlib ships with the OS, SDL_image and SDL_mixer should also be
available as precompiled frameworks from their respective download
pages.

There isn’t any package for Mac on
http://www.libsdl.org/projects/SDL_mixer/ and …/SDL_image/.

RegardsOn 18/01/2005, Bob Ippolito, you wrote:

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

but I think I downloaded the framework thing, and then its installer
told me it had installed everything I didn’t want and I had to use
the
source distro to get what I wanted. At least, that’s what I
understood :]

Well, you’re mistaken… The SDL framework isn’t missing anything as
far as I can tell. I’ve been using them for quite some time.

Looks like I wasn’t dreaming. Here is what the SDL 1.2.8 developer
package for Mac OS X says after install:

What was installed and where:
Project Stationary in /Developer/ProjectBuilder Extras
HTML documentation in /Developer/Documentation/SDL
This README in your home directory.
Package receipt in /Library/Receipts/SDL-devel.pkg

What was not installed (Available in the SDL source code):
- SDL framework.
- SDL library source code and Framework Projects.
- configure/make support (available with source code).

If the framework itself isn’t installed in the developer package, then
it’s in the runtime package. So what?

zlib ships with the OS, SDL_image and SDL_mixer should also be
available as precompiled frameworks from their respective download
pages.

There isn’t any package for Mac on
http://www.libsdl.org/projects/SDL_mixer/ and …/SDL_image/.

I could’ve sworn there was, there is support for building the
frameworks in the tarballs, anyway.

-bobOn Jan 19, 2005, at 3:47, Olivier Fabre wrote:

On 18/01/2005, Bob Ippolito, you wrote:

Well, you’re mistaken… The SDL framework isn’t missing anything as
far as I can tell. I’ve been using them for quite some time.

If the framework itself isn’t installed in the developer package, then
it’s in the runtime package. So what?

To clarify any possible confusion, we changed what’s packaged in the
SDL.framework in the 1.2.8 release. The standard SDL.framework now
contains both the runtime library and the header files. This was done
to bring it in line with Apple conventions. This used to be split into
two frameworks (runtime/headers) which was kind of weird. The header
version went into a user’s private framework directory and the runtime
was installed in the system-wide directory. This caused some confusion
with Xcode projects and also caused some headaches for multi-user
systems.

The development package now only contains Xcode/Project Builder
templates and the SDL documentation.

There isn’t any package for Mac on
http://www.libsdl.org/projects/SDL_mixer/ and …/SDL_image/.

I could’ve sworn there was, there is support for building the
frameworks in the tarballs, anyway.

There are supposed to be packages for SDL_mixer and SDL_image
somewhere on the website. I use them myself. I’m also supposed to get
around to updating their Xcode projects too.

Anyway, I think the original question was how to dynamically link your
application to SDL (dylib vs framework). Either way works. I
personally like the framework approach. It’s really easy to bundle.
It’s all drag and drop. Just copy the SDL.framework to
YourProgram.app/Contents/Frameworks
Check out GLTron or Frozen Bubble. This is how they do it. (Do a “Show
Package Contents” from Finder to see the directory structure inside
the app.)

-Eric

There isn’t any package for Mac on
http://www.libsdl.org/projects/SDL_mixer/ and …/SDL_image/.

I could’ve sworn there was, there is support for building the
frameworks in the tarballs, anyway.

There are supposed to be packages for SDL_mixer and SDL_image
somewhere on the website. I use them myself. I’m also supposed to get
around to updating their Xcode projects too.

Anyway, I think the original question was how to dynamically link your
application to SDL (dylib vs framework). Either way works. I
personally like the framework approach. It’s really easy to bundle.
It’s all drag and drop. Just copy the SDL.framework to
YourProgram.app/Contents/Frameworks
Check out GLTron or Frozen Bubble. This is how they do it. (Do a “Show
Package Contents” from Finder to see the directory structure inside
the app.)

I ported Frozen Bubble. Pathological, SolarWolf, and Blob Wars are
other SDL ports that I have done, so they also use the frameworks.

Additionally, if you build pygame, it expects to find the frameworks on
Mac OS X. I don’t think it falls back to the dylib versions
automatically (but of course you can convince it to use the generic
unix behavior if you really want to). This is also “my fault”, I don’t
have a need to support the regular builds because I don’t use them.

-bobOn Jan 19, 2005, at 19:18, E. Wing wrote:

'lo E.,

To clarify any possible confusion

I’m sorry but that didn’t work :-} … not for me anyway.

The development package now only contains Xcode/Project Builder
templates and the SDL documentation.

It would be nice if the sdl site mentionned you have to get the user
package in order to develop, and that the developer package is useful
only for Xcode/PowerBuilder. Some more information about how to include
the lib(s) into one’s application without linking statically would be
great too for beginners.

I have now recompiled SDL, libpng, libjpeg, libogg, libvorbis, SDL_mixer
and SDL_image, so I’m ready to go. Ah, I still need to
"install_name_tool" some of them :).

Thanks for the clarifications.On 20/01/2005, E. Wing, you wrote:

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

That wasn’t my point at all. There’s a difference between optimizing for
a processor, and compiling only for that processor. You can optimize the
scheduling and other such things for a specific CPU (Xcode can do this
for you, I believe.) Depending on your software project, supporting a G3
may be a total non-starter if the CPU reqs are above a certain level. So
scheduling for a G4 (to get optimal performance on the low end) at the
expense of small inefficiencies on the higher end machines (which won’t
be noticed) makes sense.

In terms of high-end game development, it’s not unreasonable to cut the
G3 out at this point; Apple doesn’t ship them anymore since the iBook
went to the G4, and it’s a real pain in some cases to conditionalize
code based on the presence of a vector unit. Unlike MMX/SSE on x86
chips, you can’t use Altivec in a function that a G3 will enter, since
the compiler adds setup code at the start of the function when it sees a
vector variable/function. This means function call overhead and/or ugly
code.

Also, by 2006, I’ll venture a guess that there’ll be at least one
commercial game shipping that’s G5-only. Granted, Doom7 and Unreal22
aren’t necessarily representative of the game industry in that they can
get away with culling the older hardware.

Furthermore, -Os can be one of the best optimizations you can apply. The
more you can fit into your i-cache the better. Apple recommends all
shipping code be -Os. So unless you know for certain that these binaries
are built optimized for size, you shouldn’t ship them.

For what it’s worth, I think this is bunk. The CPU bottleneck is almost
never the code cache, it’s the data cache.

There was a time when Apple recommended -Os, but I think they’ve quietly
stopped doing that with gcc 3.3. At least, I haven’t heard it recently.

In my experience, -O3 is the sweet spot on MacOSX with gcc 3.3 (with
-falign-loops=16, if you’re writing tight loops like blitters).

–ryan.