**** 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 protected]> wrote:
>
> Sorry, Roland talked about the 2 articles on install_name_tool.
>
> On Fri, Jul 3, 2015 at 7:26 AM, Juanjo Conti <[email protected]
> <mailto:[email protected]>> 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 protected]
> <mailto:[email protected]>> wrote:
> First result is the mike ash article I included in my first e-mail to this
> thread.
>
_______________________________________________
Cocoa-dev mailing list ([email protected])
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
