mikeash.com pyblog/friday-qa-2009-11-06-linking-and-install-names.html comments

Bruce - 2020-08-21 04:16:44

Fri, 21 Aug 2020 04:16:44 GMT

You can also use rpath to add @executable_path to the loading app.

e.g. install_name_tool -add_rpath '@executable_path' myapp

Best of both worlds.

Ken - 2020-06-24 21:45:28

Wed, 24 Jun 2020 21:45:28 GMT

"I haven't found a way to discover what directories @rpath will expand to at runtime."

Set the environmental variable DYLD_PRINT_LIBRARIES and launch the application. It will print out exactly what it's loading.

https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/LoggingDynamicLoaderEvents.html

Dhiren - 2014-07-03 09:10:19

Thu, 03 Jul 2014 09:10:19 GMT

Since with iOS 8, Dynamic Framework is allowed, Does above process is same for iOS Framework development??

Jan Weiß - 2012-10-23 11:18:06

Tue, 23 Oct 2012 11:18:06 GMT

What Jerry described above didn’t work for me. I have written a wrapper for libzip (http://nih.at/libzip/index.html) called JXZip and it uses libzip’s included Xcode project to build a framework for it.

Now JXZip is built as a framework itself so it has to include “libzip Mac.framework”. It’s “Installation Directory” (INSTALL_PATH) is already set to @rpath. I do the usual “Build Phases” dance when building JXZip.framework:
- Add the “libzip Mac” target to “Target Dependencies”
- Add the build product to “Link Binary With Libraries” and “Copy Frameworks”

As Jerry mentions above, the @loader_path is relative to the binary doing the loading. In this case it’s “JXZip”. For frameworks, the contained “Frameworks” is a subfolder of the folder where the binary is located. So we have to set “Runpath Search Paths” (LD_RUNPATH_SEARCH_PATHS) in the “Build Settings” to "@loader_path/Frameworks".

Jerry Krinock - 2012-08-20 19:08:29

Mon, 20 Aug 2012 19:08:29 GMT

In the section on @loader_path, Mike wrote that If it's a framework or plugin, though, then it's relative to that framework or plugin. More precisely, I've found that it's relative to the loading executable in the framework or plugin.

This is important if a framework is expected to be loaded by another framework. For example, when building the Sparkle framework into an app which accessed Sparkle via another framework, the app crashed upon launching outside of Xcode, because the Sparkle framework was not found, until I changed the Sparkle framework's Installation Directory from @loader_path/../Frameworks, to @loader_path/../../../../Frameworks. In this case, the old fashioned @executable_path/../Frameworks worked too (because the path starts at Contents/MacOS/MyApp). I decided that was a better choice.

Konrad Windszus - 2010-05-26 20:32:49

Wed, 26 May 2010 20:32:49 GMT

Also check out MacDependency at http://macdependency.googlecode.com which is a GUI replacement for otool and can also display used libraries with @rpath.

Jay Tuley - 2009-11-22 16:23:59

Sun, 22 Nov 2009 16:23:59 GMT

Yeah, the wording in in the man page of the Dynamic Load Editor is a little odd, The framework Programing Guide: Installing Your Framework mentions this behavior too, but also pretends like /Network/Library/Frameworks/ isn't in that list, I've never tried that location personally though.

http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/InstallingFrameworks.html#//apple_ref/doc/uid/20002261-BBCCFBJA

mikeash - 2009-11-22 03:01:10

Sun, 22 Nov 2009 03:01:10 GMT

I had no idea about this behavior. Looks like it comes from this bit in the man page:

DYLD_FALLBACK_FRAMEWORK_PATH
              This is a colon separated list of directories that contain
              frameworks. It is used as the default location for frameworks
              not found in their install path.

              By default, it is set to /Library/Frameworks:/Net-
              work/Library/Frameworks:/System/Library/Frameworks

This is really confusing wording because DYLD_FALLBACK_FRAMEWORK_PATH is not actually set on my system at all (yet the behavior works as you describe). I assume what they mean to say is that, if DYLD_FALLBACK_FRAMEWORK_PATH is not set, then the default is those paths.

Jay Tuley - 2009-11-22 02:34:13

Sun, 22 Nov 2009 02:34:13 GMT

Thank you for your article, Rpath is really interesting and useful I had no idea it had been added.

I'd like to point out though a problem with your problem examples as that problem is a bit misleading

embedded in an application or when installed to /Library/Frameworks, you have to provide two separate copies with two different install names.

If you want Foo.framework to work when embedded in an application or when installed to /Library/Frameworks, you have to provide two separate copies with two different install names. (Or manually tweak install names later on using install_name_tool.) This is doable, but annoying.

These statements would be 100% correct with "~/Library/Frameworks", however not with "/Library/Frameworks" if you set a framework to any install path whatever it may be @executable, @loader, or just a random directory, if the framework does not exist where the install name says it should, by default Mac OS X will check



/Library/Frameworks 

/Network/Library/Frameworks 

/System/Library/Frameworks

So if a framework is compiled with @executable_path or @loader_path it is still consumable by an app that wants to put in in any of the above 3 fallback directories (and luckily /Library/Frameworks is most likely and most common alternative).

Certainly rpath is more flexible and should be used when targeting only 10.5 or later, but for the common specific case of designing a framework to be used in a bundle or in /Library, frameworks targeting 10.4 using @loader_path aren't really as annoying as mentioned above.

Jamie Hope - 2009-11-10 17:52:04

Tue, 10 Nov 2009 17:52:04 GMT

OK, thanks. It seems odd to me that there's nothing less clunky, but something like this works well enough:

#!/bin/bash

for file in $@; do
echo "$file":
otool -l $file | grep -A 3 LC_RPATH | grep path
done

Ben - 2009-11-09 03:07:54

Mon, 09 Nov 2009 03:07:54 GMT

Mike,
Wanted to thank you for your series of Friday Q&A. It's hard to find deep OS and development topics covered in such detail for the Mac platform, and your blog is a precious resource.

Thanks
Ben

mikeash - 2009-11-09 01:56:48

Mon, 09 Nov 2009 01:56:48 GMT

I don't see a way to directly print only a binary's rpath list, but if you do otool -l to list the binary's load commands, the rpaths will show up as LC_RPATH commands.

Jamie Hope - 2009-11-09 01:29:48

Mon, 09 Nov 2009 01:29:48 GMT

Thanks, Mike!

Is there a way to examine a binary to see what list of rpath locations it was compiled with? On Leopard, I can use otool -L to see link entries of the form "@rpath/Foo.framework/Versions/A/Foo", but I haven't found a way to discover what directories @rpath will expand to at runtime.

Since Brent has mentioned the Xcode way to use -rpath, I'll mention that if you invoke the linker through gcc (on the command line, or in a Makefile, etc) you have to use the "-Wl,option" gcc flag. So, "-rpath path" becomes "-Wl,-rpath,path".

Also: if you're compiling a library and want the linker to look for a dependency in the same directory as the library, you have to do "-rpath @loader_path/.", not just "-rpath @loader_path". That one took me a little while to figure out.

Brent Royal-Gordon - 2009-11-07 13:24:46

Sat, 07 Nov 2009 13:24:46 GMT

As it turns out, poking around this morning revealed a "Runtime Search Paths" option specifically for rpaths you want to add; using that instead of an -rpath option in Other Linker Flags allowed my program to use the embedded framework.

Thanks for the explanation, Mike--this has had me blocked on a side project for a while!

mikeash - 2009-11-07 02:19:57

Sat, 07 Nov 2009 02:19:57 GMT

My intent is to just explain the theory. Other Linker Flags ought to work fine. If you're having specific problems with Xcode, I recommend Apple's xcode-users list.

Brent Royal-Gordon - 2009-11-07 01:53:33

Sat, 07 Nov 2009 01:53:33 GMT

This is great stuff, but do you think you can get it down to the concrete level of "here's where you put this setting in Xcode"? In particular, where does the -rpath parameter go? I tried using it in the "Other Linker Flags" build setting on my application's target, but the linker complains that it can't find the path.