iDevGames Forums
linking with a .dylib problem - Printable Version

+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Game Programming Fundamentals (/forum-7.html)
+--- Thread: linking with a .dylib problem (/thread-1498.html)



linking with a .dylib problem - Jamie W - Apr 5, 2009 01:16 AM

Hi,

I'm trying to link my app with a .dylib (dynamic library). My app is compiling fine, but when it comes to debugging (or running) in, the debugger reports that it can't find the .dylib.

I'm using scode by the way.

I've put the .dylib, in my projects root folder. I'm guessing either that's the wrong place for it to go, or, I need to setup something in the build options (there are so many of them!) or is it something to do with the bundle?


linking with a .dylib problem - wadesworld - Apr 5, 2009 08:47 PM

What kind of dylib? One that's included in OS X? If it is, simply adding the dylib to your project should be all you need to do.

If not, you need to ensure that:

1) The user installs the dylib in a place like /usr/local/lib and you set your library search paths so your application can find it.

2) The dylib is placed in the application bundle and the install_name of the dylib is changed to point to its location in the bundle. This is the approach you want to use. You add a copy files build phase to copy the dylib to application/Contents/Frameworks and then use install_name_tool with the -id option to change the embeded location of the dylib to "@executable_path/../Frameworks/libname.dylib" (where libname is the name of your library).

Note that the string length of the new location of the library should be shorter than the old location's string length. If it's not, you should build your app with the -headerpad_max_install_names option enabled.


linking with a .dylib problem - Jamie W - Apr 6, 2009 03:47 AM

Thanks.

Yeah, the .dylib is not included with OS X (it's a sound library (to play wavs, oggs, mods etc). I will need to distribute it with the game intall file bundle (all this bundle stuff is still a bit new to me).

So if I change the install name in the .dylib; then when I compile my app (linking to the .dylib), my app stores a reference to the install name of the .dylib, and will look for it in that location when my app loads up?

Is that correct?

Also, I want to put the .dylib in Contents/Frameworks/<here>

That's the correct place for it to go? It seems right.

Sorry for the million questions, and thanks for your patience; it's all a bit new to me still. Smile


linking with a .dylib problem - Jamie W - Apr 6, 2009 05:56 AM

WOW it works! Smile

I didn't have access to the .dylib's source, so couldn't compile it etc.

But I managed to change the install_name, and setup the copy files thing, so it's in the Frameworks folder in my apps bundle.

The thing with the new install_name, must be longer than the old one; is that so the new one can fit in to the limited amount of bytes within the .dylib, that exist for the old install_name?

I think in my case, the new install_name was longer than the old one, but perhaps the .dylib was compiled with the maximum padding, so there was no need for me to get the sources and re-compile it with the -headerpad_max_install_names option.

Does that make sense?

Unless of course, I've writted over the old one, and also over some other important contents in the .dylib!

Would the install_name_tool report it, if that was the case?


linking with a .dylib problem - wadesworld - Apr 7, 2009 10:53 AM

Quote:I think in my case, the new install_name was longer than the old one, but perhaps the .dylib was compiled with the maximum padding, so there was no need for me to get the sources and re-compile it with the -headerpad_max_install_names option.

You misunderstood - make sure the binary is compiled with that option - i.e. your application.

However, looking at the man page more closely, it appears that this option is only needed if you had previously linked your application with a shorter name and plan to change it later using install_name_tool. So if you're not running install_name_tool to modify your already-built application, then I think you'd be OK.