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:30:28 +0800
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.
>
> Kevin
>
>> On 3 Jul 2015, at 10:48, Roland King <email@hidden <mailto:email@hidden>> wrote:
>>
>> www.google.com <http://www.google.com/>
>>
>> "mike ash install_name_tool”
>>
>>
>>> On 3 Jul 2015, at 17:45, Juanjo Conti <email@hidden <mailto:email@hidden>> wrote:
>>>
>>> Could you point me to that articles please?
>>>
>>> On Fri, Jul 3, 2015 at 6:38 AM, Roland King <email@hidden <mailto:email@hidden>> wrote:
>>>
>>>> On 3 Jul 2015, at 17:29, Kevin Meaney <email@hidden <mailto:email@hidden>> wrote:
>>>>
>>>> I’m not sure either of those will work.
>>>>
>>>> On 3 Jul 2015, at 10:07, Roland King <email@hidden <mailto:email@hidden>> 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@hidden>>
>>> 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@hidden>>
> Software Engineer - Carousel Apps <https://carouselapps.com/>
>
>
>
>
> --
> Juanjo Conti <jjconti <http://goog_2023646312/>@carouselapps.com <mailto:email@hidden>>
> 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@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