Macintosh linking problem - @executable_path

[Rainer Deyke]

I have had several reports of the Macintosh version of Lightslayer (http://eldwood.com/lightslayer) (direct download link (http://eldwood.com/lightslayer/ltslyr.dmg)) not starting, even though it runs correctly on my own Mac Mini and at least some other Macs. One user sent in a crash log, which contains the following (OS X 10.4):Link (dyld) error:

Library not loaded: @executable_path/libSDL-1.2.0.dylib
Referenced from: /Applications/Lightslayer.app/Contents/MacOS/lightslayer
Reason: image not found

Another sent in a crash log containing the following (OS X 10.3.9):Link (dyld) error:

dyld: /Volumes/Lightslayer/Lightslayer.app/Contents/MacOS/lightslayer can't open library: @executable_path/libSDL-1.2.0.dylib (No such file or directory, errno = 2)


However, if I examine the bundle, it clearly contains the file libSDL-1.2.0.dylib in the Contents/MacOS directory. Is there any Macintosh expert here who can tell me what I'm doing wrong?

[Gnatinator]

Embedding the *.dylib properly can be a pain in the ass. Proper instructions on how to do it can be found here. (http://qin.laya.com/tech_coding_help/dylib_linking.html)

I would recommend just using the *.framework, it's much easier. (embed the *.framework by dropping it into a "Frameworks" folder beside the resources and macos folders)

[Rainer Deyke]

I am aware of that page, and I'm pretty sure that I followed the instructions properly. The only difference is that I placed the dylib files in the same directory as the executable (@executable_path/lib_name) instead of in ../Frameworks (@executable_path/../Frameworks/lib_name). I don't see how this could be the cause of my problem, and I have no way of testing if it is the cause of my problem. The way I see it, platform-specific dylib files should go into the same platform-specfic directory as the executable, and only true frameworks (which are also bundles and may therefore contain code for multiple platforms) should go in the Frameworks directory. Am I wrong?

Using frameworks would require me to write scripts that turn my dylibs into frameworks. It's possible, but it's also a lot of extra work, with a lot of extra chances for something to go wrong.

[Gnatinator]

I'm assuming your just trying to embed the SDL library into your app so it will work on systems without it?

Keep it simple. Grab an existing SDL 1.2.0 *.framework from an another game/app and throw it in. No need to make your own.

[Rainer Deyke]

I don't like the idea of embedding the SDL framework for the following reasons:
I don't like trying things at random in hope that they will fix something.
I have no way of testing if this actually works.
I use other dylibs which aren't available in framework form.
Frameworks increase the download size.
I generally don't trust code that I didn't compile myself, although in the case of SDL I don't expect any problems on OS X.

BTW, I found the problem. It turns out that the libSDL-1.2.0.dylib I had included in the bundle was just a symbolic link to libSDL-1.2.0.7.2.dylib, which of course I had not included in the bundle. A stupid mistake, but not one that I am likely to repeat now that I know what to watch out for.