Re: Problem having a framework working in one of my targets (a screensaver)
Re: Problem having a framework working in one of my targets (a screensaver)
- Subject: Re: Problem having a framework working in one of my targets (a screensaver)
- From: Roland King <email@hidden>
- Date: Fri, 03 Jul 2015 20:34:52 +0800
**** Resending because the last one was > 25K and got held, apologies for the dupe which will no-doubt eventually arrive ****
Perhaps it was only one - thought it was two - either way I learned most of what I knew about how dynamic loading works from that article + a bit of reading afterwards.
So I have finally 15 minutes before Friday’s guests turn up, if I understand this rather long thread ..
You have a 3rd party library you’re linking into your app (a screensaver). When you link it in the screen save executable can’t find it. It can’t find it because the path it’s looking for it, which is buried in the load instructions in your binary, is @executable_path/../<rest of path> but that’s not where you’re installing it, which is probably in ../Frameworks or similar.
So where does the @executable_path/../<stuff> come from? That is the install name of the library you’re linking in, the 3rd party one. The install name is set when you build something and is a promise to the linker that you’re going to install the shared library/dynamic library/framework in that place, thats why it’s called the install name. So when whoever it was built it, built it, they specified @executable_path/../etc and that’s probably where most people install it, in the Frameworks directory just under their app in the bundle.
I don’t know what the executable_path is for a screensaver, you’d think it was very much the same thing. So first simplest option is to work out what that is and then just put the library at the place it expects to be, @executable_path/../Frameworks/<lots of garbage>. As long as that’s within your bundle somewhere, trivial to do. You can even put it somewhere else and put a symlink in the bundle.
If you don’t want to do that or for some reason can’t. The path put into your final binary is the ‘install name’ of the library from the library itself. You can’t rebuild the library but because this is a REALLY common problem which happens all the time, there exists an install_name_tool which lets you change it (as long as the new one is shorter than the old one and it helps if the developer was nice and padded the original one to leave lots of space).
I believe the install name of an object can be found by running ‘otool -D <object>’, if you do that on the library you’re linking, it should say @executable_path/…
If you want to change it to something like @rpath/whatever then
install_name_tool -id @rpath/whatever <object>
You run that on the original 3rd party library, it changes the install name compiled in to one of your choosing, and you can have whatever you like and then add whatever search paths to your binary you want which will then find it. @rpath/ is a good choice because you can always add a search path which will find it wherever you put it (and change it for different apps).
So change the install name in the 3rd party library, re-link your app, the load commands should now reflect the install name you just chose. Job done.
> On 3 Jul 2015, at 18:28, Juanjo Conti <email@hidden> wrote:
>
> Sorry, Roland talked about the 2 articles on install_name_tool.
>
> On Fri, Jul 3, 2015 at 7:26 AM, Juanjo Conti <email@hidden <mailto:email@hidden>> wrote:
> Yes, but he doesn't explain install_name_tool there. You said there were 2 articles about install_name_tool.
>
> On Fri, Jul 3, 2015 at 6:56 AM, Kevin Meaney <email@hidden <mailto:email@hidden>> wrote:
> First result is the mike ash article I included in my first e-mail to this thread.
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden