[SDL] Re: SDL digest, Vol 1 #961 - 16 msgs

Darrell Walisser walisser at mac.com
Mon Nov 10 16:17:01 PST 2003


On Nov 10, 2003, at 3:01 PM, sdl-request at libsdl.org wrote:

> Message: 5
> Date: Mon, 10 Nov 2003 03:01:41 +0100
> From: =?iso-8859-1?Q?H=E5kon?= Skjelten <skjelten at pvv.org>
> To: sdl at libsdl.org
> Subject: [SDL] Problem porting SDL project to MacOSX.
> Reply-To: sdl at libsdl.org
>
> 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 <binary> 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.





More information about the SDL mailing list