Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

vvrinne

macrumors member
Original poster
Feb 28, 2010
53
23
Helsinki, Finland
I've been banging my head against the wall for a while with this one. Would appreciate any help!

I've got a scenario for testing purposes. I have one Framework project in XCode that has one HelloWorld class (and header). I have set the "Installation directory" to "@executable_path/../Frameworks" and have set the single header file as public. The framework bundle that is being built looks ok to me.

I have a second application project that includes the .framework bundle from the build-directory of the framework project (build/release/TestFramework.framework). The framework is included under "Frameworks/Linked Frameworks" and I have created the Copy Files build target. Everything compiles ok and the application bundle looks ok as well. The framework does get included in the Frameworks-directory within the .app bundle.

Now even though everything looks good to me I am still getting "image not found" errors from dyld when I try to run that app. When I run 'otool -L' on my app I see that the path to my framework is still set as /Users/myuser/Library/Frameworks. From what I've read I am under the impression that this should now be the value of the "Installation Directory" I have changed in the build settings for my framework but for some reason it has not changed. I have cleaned and re-built everything.

I am a noob with XCode and Cocoa so I am probably missing something obvious. Huge thanks to anybody that can help!
 

vvrinne

macrumors member
Original poster
Feb 28, 2010
53
23
Helsinki, Finland
Ok typical that after a couple of hours of banging head to wall I figure this out within minutes of writing this thread.

Turns out I had a build variable called 'Dynamic Library Install Name' still set to some static path. Simply emptying that variable was enough to fix the issue. I don't recall this variable mentioned in any of the numerous guides and references I scanned when debugging but simply removing the value from it seems to have fixed this problem.
 

vvrinne

macrumors member
Original poster
Feb 28, 2010
53
23
Helsinki, Finland
Ok fudge, I hate monologues but it turns out I didn't actually fix it so any help is still appreciated :)

Removing LC_ID_DYLIB did make it work but it seems it just made it so that the location of the framework is set at compile time instead of runtime. So **** gets linked against the absolute path of the framework included in the application project but obviously I want dyld to look for it in @executable_path or @rpath or similar at runtime.
 

Detrius

macrumors 68000
Sep 10, 2008
1,623
19
Apex, NC
Sounds like the install name is off. It's been quite a while since I've had to mess with this, so I don't have a direct answer for you. Clearly, you see that "otool -L" will show you what things are linked to. What's handy is that you can use "install_name_tool" to change these values after everything has been linked.

It appears that "Dynamic Library Install Name" is the current setting you should look at with Xcode.
 

vvrinne

macrumors member
Original poster
Feb 28, 2010
53
23
Helsinki, Finland
Thanks Detrius. You put me on the right track. It appears that "Dynamic Library Install Name" is indeed the variable that needs to be changed.

I was way off base with the stuff I was reading on the net. It's incredible the amount of ******** that is available as "guides" regarding this issues when googling it. Even the stuff at developer.apple.com didn't help although I guess there has to be something I just managed to miss.

Here's the solution that worked for me in case this gets indexed by google and somebody else finds it:

The "Dynamic Library Install Name" build variable in the framework project needed to be set to something like "@loader_path/../Frameworks/TestFK.framework/TestFK". @loader_path gets resolved at runtime to /Content/MacOS path within you application bundle. Nothing has to be done to the application project after this, other than including the framework and making sure it gets copied to /Content/Frameworks inside the bundle.

Huge relief but god damn I've never ran into so much misinformation on a programming issue before. I guess Apple has just changed how this thing work in every major OS release since like 10.3 and most of the stuff popping up on google is outdated and not working.

Maybe I'm just an idiot but after several hours of googling I didn't find a SINGLE guide that mentioned that "Dynamic Library Install Name" is what you should be using and NOT "Installation Directory". But yeah had I actually understood all the stuff I now understand about @rpath, @loader_path etc. I would have had it solved much sooner. Just haven't had to do this much head banging over a programming issue in years :)
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.