OS X frameworks and packages

I really think we should continue this on-list for the archives… The
summary of off-list discussion so far is:

OS X frameworks are useful if you’re using OS X’s XCode or Package
Builder to build your app. Of course you would want to put the
framework inside your application bundle, rather than requiring the
user to install it into /Libraries/Frameworks .

OS X frameworks are not useful if you want to build an existing
autoconf-based project. In this case, you should use a Unix-like SDL
package, such as those installed by Fink or DarwinPorts. These install
sdl-config and libraries just like Linux/BSD/etc packages (but into /sw
or /opt), which means that build systems depending on sdl-config “just

However, you cannot assume that users have installed the
Fink/DarwinPorts package on their own systems, so you should statically
link with SDL. You cannot use the linker’s -static argument (you cannot
statically link with OS X’s system libraries; see
http://developer.apple.com/qa/qa2001/qa1118.html). Instead you must
link by directly referencing the .a files, e.g. “gcc mycode.o
/sw/lib/libSDL.a -o mycode”. In SDL 1.2.7, OS X’s “sdl-config
–static-libs” will emit the correct output, but in earlier versions
this was not the case. However, I notice that sdl.m4 (as found in
SDL-1.2.7 source) does not seem to support --static-libs, so this will
require custom autoconf hacking. Anyone want to comment on that?

It’s important to note that statically linking SDL is not possible for
commercial programs (because of the LGPL license). One alternative to
static linking, which Ryan Gordon used in UT2003, is to dynamically
link with SDL but include libSDL.dylib in the application bundle
itself. In this case you must somehow link with
"@executable_path/libSDL.dylib" (as seen in "otool -L ",
but I don’t know how to do this. It may require building your own
libSDL.dylib, and specifying the “install path” as “@executable_path”.