SDL digest, Vol 1 #961 - 16 msgs

Message: 5

Hi

I’ve been porting my SDL game to a numerous platforms lately but the
Mac OSX
port gave me some frustration.

When I compile my project in Mac OSX (at sourceforge’s compile farm) it
dynamically links in libsdl, libpng, libvorbis, libxml2… etc. and
all seems
fine - at the compile farm. When I copy my binary file to a local Mac
it
won’t find the dylibs automatically if not the libraries are at the
exact same
location as on the compile farm (which they are not). This lead me to
use
the DYLD_LIBRARY_PATH environment variable. For this to work I had to
copy all the dylibs from the compile farm - but it worked.

Now I would like to make a bundle (that’s what most people do right?)
of my
game - but now I can’t make it find my dylibs inside the bundle (I’ve
tried
using the LSEnvironment variable in Info.plist) - no luck.

Looking at other projects I see they usually have no extra libraries in
their bundle… is it possible to link the source static?

Yep. You’ll have to add several more libs to the link line, see
sdl-config --static-libs

Others have Frameworks of libsdl - but I can’t find Frameworks for
libpng,
libvorbis, libiconv… etc.

Since I don’t have root access ‘fink’ is of no help. The bundle have
to be
self-contained.

How do you Mac OSX game programmers solve this problem?
(I’ve not used anything else than GNU/Linux for many years so I’m
completely
new to Mac OSX).

With plain .dylibs, you use the -dylib_file flag (see “man ld”) when
linking them to set the install location to somewhere else other than
the directory it was linked from. Usually, you locate it in the same
directory as the executable or up a level or so:

(other ld flags here) -dylib_file
/usr/local/lib/libsdl.dylib:@executable_path/libsdl.dylib

Then check your binaries/dylibs with:

otool -L to make sure they are linking with the right path,
for example:

otool -L ~/Applications/Camino.app/Contents/MacOS/Camino
/Users/walisser/Applications/Camino.app/Contents/MacOS/Camino:
@executable_path/libxpcom.dylib (compatibility version 1.0.0,
current version 1.0.0)
@executable_path/libplds4.dylib (compatibility version 1.0.0,
current version 1.0.0)
@executable_path/libplc4.dylib (compatibility version 1.0.0,
current version 1.0.0)
@executable_path/libnspr4.dylib (compatibility version 1.0.0,
current version 1.0.0)
@executable_path/libsmime3.dylib (compatibility version 1.0.0,
current version 1.0.0)
@executable_path/libssl3.dylib (compatibility version 1.0.0,
current version 1.0.0)
@executable_path/libnss3.dylib (compatibility version 1.0.0,
current version 1.0.0)
@executable_path/libsoftokn3.dylib (compatibility version
1.0.0, current version 1.0.0)
@executable_path/libxpcom_compat.dylib (compatibility version
1.0.0, current version 1.0.0)
@executable_path/libmozjs.dylib (compatibility version 1.0.0,
current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 63.0.0)
/usr/lib/libz.1.1.3.dylib (compatibility version 1.0.0, current
version 1.1.3)
(…)

This is the exact same trick used with the Project Builder frameworks,
using the INSTALL_PATH target setting. Note: you can use pbxbuild
from the command line to build the frameworks for SDL, SDL_mixer, etc.
on the sf server, in which case you use -F to add framework search
paths and -framework SDL, etc to link to the library. The otool trick
still applies to check that the end result is locating the shared
libraries where you want them to be.On Nov 10, 2003, at 3:01 PM, sdl-request at libsdl.org wrote:

Date: Mon, 10 Nov 2003 03:01:41 +0100
From: Hakon Skjelten
To: sdl at libsdl.org
Subject: [SDL] Problem porting SDL project to MacOSX.
Reply-To: sdl at libsdl.org