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: Juanjo Conti <email@hidden>
- Date: Fri, 03 Jul 2015 15:10:36 -0300
I also tried to change the name in the original framework, but that result
in a compilation error <-- and that was because the name was a path instead
of a file. Thanks! Now it's working!
Thanks for the help Roland and Kevin, if you use Mac, we're happy to offer
you a free license of https://screensaver.ninja/
On Fri, Jul 3, 2015 at 2:12 PM, Roland King <email@hidden> wrote:
> for a start @rpath/
>
> won’t work.
>
> The id name is the actual name of the file, when you substitute the value
> of ‘rpath’ in it needs to resolve to an file. So it needs to be
> @rpath/<filename>
>
> You must be install_name_tool’ing the wrong file. The file you’re
> changing, the one in BUILT_PRODUCTS_DIR is not the same one you’re linking
> with. Think about it, that path you are seeing in your final binary, it’s
> not random, it’s coming out of the framework you are linking with, it has
> to, there is no other place it could come from, the linker didn’t just make
> it up, so if you are changing the one in BUILT_PRODUCTS_DIR, and the one in
> BUILT_PRODUCTS_DIR has the right install name and the one in your final
> binary has the original one, then that cannot be the one you’re actually
> linking with. This string is embedded during the link process, so the file
> the linker finds on the command-line is the one it uses, not the one you
> later copy into the bundle.
>
> Let me make it really clear. The name embedded in your final binary comes
> from the install name set in the library/framework you link with. There is
> nowhere else it could come from, that is the only information the linker
> has. So if your final binary has @exectuable_path in it, then the framework
> you are actually linking with has that install name set on it.
>
> Why don’t you copy the original Paddle framework somewhere far far away
> and change the original one in your project to have the correct install
> name so there is nothing in the entire build, nothing on your entire
> machine, which has the original name.
>
> I picked @rpath/bananas/are/tasty to show quite conclusively that the load
> name is copied verbatim from somewhere in the framework and the place in
> the framework from which it’s copied is the install name (and that
> install_name_tool -id changes that name). If you are still seeing the old
> path, then the library you’re linking with is not the one you’ve changed.
>
>
>
> On 4 Jul 2015, at 00:32, Juanjo Conti <email@hidden> wrote:
>
> Roland, thanks for taking the time for explaining this. I think I'm closer
> to the solution but I didn't make it work yet.
>
> The screensaver ends installed in ~/Library/Screen Savers/Ninja.saver/
>
> I was able to cd there and
> cd Contents/Frameworks/Paddle.framework/Versions/A, run install_name_tool
> command and change the name for the Paddle binary. But I don't know how to
> re link it.
>
> So I went to XCode and for the Saver target I added a Run Script phase in
> Build Phases, between Copy File (the framework) and Link Binary With
> Libraries. The script is:
>
> install_name_tool -id @rpath/
> $BUILT_PRODUCTS_DIR/Ninja.saver/Contents/Frameworks/Paddle.framework/Versions/A/Paddle
>
> After building and installing the screensaver in its destination folder, I
> can check with otool that the change was done:
>
> ~/Library/Screen
> Savers/Ninja.saver/Contents/Frameworks/Paddle.framework/Versions/A$ otool
> -D Paddle
>
> Paddle:
>
> @rpath/
>
> But, when I run the screensaver, I still get the error:
>
> Jul 3 13:30:46 ironbird.local ScreenSaverEngine[74782]: Error loading
> /Users/juanjo/Library/Screen Savers/Ninja.saver/Contents/MacOS/Ninja:
> dlopen(/Users/juanjo/Library/Screen
> Savers/Ninja.saver/Contents/MacOS/Ninja, 265): Library not loaded:
> @executable_path/../Frameworks/Paddle.framework/Versions/A/Paddle
>
> Referenced from: /Users/juanjo/Library/Screen
> Savers/Ninja.saver/Contents/MacOS/Ninja
>
> Reason: image not found
>
> What can be happening? I think this is related to Kevin doubt.
>
> Thanks in advance for your patient and time.
> On Fri, Jul 3, 2015 at 10:57 AM, Roland King <email@hidden> wrote:
>
>> Downloading the zip file referenced earlier and using a simple main.c
>>
>> $ clang -x c -o main.o -c main.c
>> $ clang main.o -o main
>> $ otool -L main
>> main:
>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
>> current version 1213.0.0)
>>
>> adding the framework right from the unzipped zip and then otool’ing it
>>
>> $ clang main.o -F ~/Downloads/Mac-Framework-master -framework
>> Paddle -o main
>> $ otool -L main
>> main:
>>
>> @executable_path/../Frameworks/Paddle.framework/Versions/A/Paddle
>> (compatibility version 1.0.0, current version 1.0.0)
>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
>> current version 1213.0.0)
>>
>> That’s that @executable_path from the library, using otool -D on it ...
>>
>> $ otool -D
>> ~/Downloads/Mac-Framework-master/Paddle.framework/Paddle
>>
>> /Users/rols/Downloads/Mac-Framework-master/Paddle.framework/Paddle:
>> @executable_path/../Frameworks/Paddle.framework/Versions/A/Paddle
>>
>> now update it and check it again
>>
>> $ install_name_tool -id @rpath/bananas/are/tasty
>> ~/Downloads/Mac-Framework-master/Paddle.framework/Paddle
>>
>> $ otool -D
>> ~/Downloads/Mac-Framework-master/Paddle.framework/Paddle
>>
>> /Users/rols/Downloads/Mac-Framework-master/Paddle.framework/Paddle:
>> @rpath/bananas/are/tasty
>>
>> and re-link main and then otool it again
>>
>> $ clang main.o -F ~/Downloads/Mac-Framework-master -framework
>> Paddle -o main
>> $ otool -L main
>> main:
>> @rpath/bananas/are/tasty (compatibility version 1.0.0,
>> current version 1.0.0)
>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
>> current version 1213.0.0)
>>
>> That’s where it comes from - that’s how you can change it. Don’t know
>> what you’re seeing.
>>
>> > On 3 Jul 2015, at 21:19, Kevin Meaney <email@hidden> wrote:
>> >
>> >>
>> >> 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.
>> >
>> > The @executable_path for the Screen saver will be the path to the
>> executable process that loads the OP’s screen saver plugin. in this case
>> ScreenSaverEngine.
>> >
>> >>
>> >> If you want to change it to something like @rpath/whatever then
>> >>
>> >> install_name_tool -id @rpath/whatever <object>
>> >
>> > This is where I get confused. In my project not the original posters my
>> framework has Installation Directory set to @rpath and everything works as
>> I need it to thanks to that Mike Ash article. But if I do otool -D on the
>> framework then I see @executable_path … etc. Making me conclude the rpath
>> information was stored separately in the binary to the install name so my
>> thinking was that modifying the install name wouldn’t help.
>> >
>> > Kevin
>> >
>>
>>
>
>
> --
> Juanjo Conti <jjconti <http://goog_2023646312/>@carouselapps.com
> <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
<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