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.
>
> Kevin
>
>> On 3 Jul 2015, at 10:48, Roland King <[email protected] <mailto:[email protected]>>
>> wrote:
>>
>> www.google.com <http://www.google.com/>
>>
>> "mike ash install_name_tool”
>>
>>
>>> On 3 Jul 2015, at 17:45, Juanjo Conti <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Could you point me to that articles please?
>>>
>>> On Fri, Jul 3, 2015 at 6:38 AM, Roland King <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>> On 3 Jul 2015, at 17:29, Kevin Meaney <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> I’m not sure either of those will work.
>>>>
>>>> On 3 Jul 2015, at 10:07, Roland King <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>> There’s two other options
>>>>>
>>>>> 1) Use install_name_tool to change the name in the library to the one you
>>>>> want. If it’s shorter, and it should be as the install name in that
>>>>> library seems rather long, you can do that
>>>>
>>>> I don’t think modifying the Installation Directory will work. I’ve checked
>>>> my framework using otool as Juanjo mentioned he did. Building my Framework
>>>> I’ve set Installation Directory to @rpath but the name I see using otool
>>>> still says @executable_path/… etc. so there is some information set
>>>> elsewhere which informs the linker. So I don’t think editing the path
>>>> using install_name_tool will help.
>>>
>>> I think it’ll work just fine, that’s what install_name_tool is there for,
>>> that’s what I’ve used it for and many others too. You change the install
>>> name of the thing you’re linking to before you link it and it shows up in a
>>> the right place in the final executable.
>>>
>>> I believe Mike Ash did a series of two great articles on this.
>>>
>>>
>>>
>>>
>>> --
>>> Juanjo Conti <jjconti <http://goog_2023646312/>@carouselapps.com
>>> <mailto:[email protected]>>
>>> Software Engineer - Carousel Apps <https://carouselapps.com/>
>>>
>>>
>>> Carousel Apps Limited, registered in England & Wales with registered number
>>> 7689440 and registered office Unit 2 Artbrand Studios, 7 Leathermarket
>>> Street, London SE1 3HN. Any communication sent by or on behalf of Carousel
>>> App Ltd or any of its subsidiary, holding or affiliated companies or
>>> entities (together "Watu") is confidential and may be privileged or
>>> otherwise protected. If you receive it in error please inform us and then
>>> delete it from your system. You should not copy it or disclose its contents
>>> to anyone. Messages sent to and from Watu may be monitored to ensure
>>> compliance with our internal policies and to protect our business. Emails
>>> are not secure and cannot be guaranteed to be error free. Anyone who
>>> communicates with us by email is taken to accept these risks.
>>
>
>
>
>
> --
> Juanjo Conti <jjconti <http://goog_2023646312/>@carouselapps.com
> <mailto:[email protected]>>
> Software Engineer - Carousel Apps <https://carouselapps.com/>
>
>
>
>
> --
> Juanjo Conti <jjconti <http://goog_2023646312/>@carouselapps.com
> <mailto:[email protected]>>
> Software Engineer - Carousel Apps <https://carouselapps.com/>
>
>
> Carousel Apps Limited, registered in England & Wales with registered number
> 7689440 and registered office Unit 2 Artbrand Studios, 7 Leathermarket
> Street, London SE1 3HN. Any communication sent by or on behalf of Carousel
> App Ltd or any of its subsidiary, holding or affiliated companies or entities
> (together "Watu") is confidential and may be privileged or otherwise
> protected. If you receive it in error please inform us and then delete it
> from your system. You should not copy it or disclose its contents to anyone.
> Messages sent to and from Watu may be monitored to ensure compliance with our
> internal policies and to protect our business. Emails are not secure and
> cannot be guaranteed to be error free. Anyone who communicates with us by
> email is taken to accept these risks.
_______________________________________________
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]
