[PATCH] Use @loader_path instead of @executable_path for framework install names

[BJ Homer]

Growl.xcodeproj/project.pbxproj | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)

# HG changeset patch
# User BJ Homer
# Date 1265695293 25200
# Node ID 8fe58682b38566e76662d0a2655725e5180aa0d7
# Parent d8b57dfcd2ae3375532602aee05a36ac99cbc32d
Use @loader_path instead of @executable_path for framework install names.

diff --git a/Growl.xcodeproj/project.pbxproj b/Growl.xcodeproj/project.pbxproj
--- a/Growl.xcodeproj/project.pbxproj
+++ b/Growl.xcodeproj/project.pbxproj
@@ -3704,7 +3704,7 @@
GCC_SYMBOLS_PRIVATE_EXTERN = NO;
INFOPLIST_FILE = "Framework/Resources/Growl.framework-Info.plist";
INFOPLIST_PREPROCESS = YES;
- INSTALL_PATH = "@executable_path/../Frameworks";
+ INSTALL_PATH = "@loader_path/../Frameworks";
LIBRARY_STYLE = DYNAMIC;
MACH_O_TYPE = mh_dylib;
MACOSX_DEPLOYMENT_TARGET = 10.5;
@@ -3766,7 +3766,7 @@
GCC_SYMBOLS_PRIVATE_EXTERN = NO;
INFOPLIST_FILE = "Framework/Resources/Growl-WithInstaller.framework-Info.plist";
INFOPLIST_PREPROCESS = YES;
- INSTALL_PATH = "@executable_path/../Frameworks";
+ INSTALL_PATH = "@loader_path/../Frameworks";
LIBRARY_STYLE = DYNAMIC;
MACH_O_TYPE = mh_dylib;
MACOSX_DEPLOYMENT_TARGET = 10.5;
@@ -4773,7 +4773,7 @@
GCC_SYMBOLS_PRIVATE_EXTERN = NO;
INFOPLIST_FILE = "Framework/Resources/Growl.framework-Info.plist";
INFOPLIST_PREPROCESS = YES;
- INSTALL_PATH = "@executable_path/../Frameworks";
+ INSTALL_PATH = "@loader_path/../Frameworks";
LIBRARY_STYLE = DYNAMIC;
MACH_O_TYPE = mh_dylib;
MACOSX_DEPLOYMENT_TARGET = 10.5;
@@ -4810,7 +4810,7 @@
GCC_SYMBOLS_PRIVATE_EXTERN = NO;
INFOPLIST_FILE = "Framework/Resources/Growl.framework-Info.plist";
INFOPLIST_PREPROCESS = YES;
- INSTALL_PATH = "@executable_path/../Frameworks";
+ INSTALL_PATH = "@loader_path/../Frameworks";
LIBRARY_STYLE = DYNAMIC;
MACH_O_TYPE = mh_dylib;
MACOSX_DEPLOYMENT_TARGET = 10.5;
@@ -4846,7 +4846,7 @@
GCC_SYMBOLS_PRIVATE_EXTERN = NO;
INFOPLIST_FILE = "Framework/Resources/Growl-WithInstaller.framework-Info.plist";
INFOPLIST_PREPROCESS = YES;
- INSTALL_PATH = "@executable_path/../Frameworks";
+ INSTALL_PATH = "@loader_path/../Frameworks";
LIBRARY_STYLE = DYNAMIC;
MACH_O_TYPE = mh_dylib;
MACOSX_DEPLOYMENT_TARGET = 10.5;
@@ -4884,7 +4884,7 @@
GCC_SYMBOLS_PRIVATE_EXTERN = NO;
INFOPLIST_FILE = "Framework/Resources/Growl-WithInstaller.framework-Info.plist";
INFOPLIST_PREPROCESS = YES;
- INSTALL_PATH = "@executable_path/../Frameworks";
+ INSTALL_PATH = "@loader_path/../Frameworks";
LIBRARY_STYLE = DYNAMIC;
MACH_O_TYPE = mh_dylib;
MACOSX_DEPLOYMENT_TARGET = 10.5;

[Peter Hosey]

On Feb 8, 2010, at 22:17:12, BJ Homer wrote:
> Use @loader_path instead of @executable_path for framework install
> names.

What's the practical benefit of this?

[BJ Homer]

@executable_path refers to the main executable. @loader_path refers to
the binary that actually linked against the framework. Often they're
the same, but not always. If you link to Growl in a prefPane,
@executable_path refers to "/Applications/System Preferences.app/
Contents/MacOS/". @loader_path refers to "/Library/Preference Panes/
MyPane.prefPane/Contents/MacOS/". The same thing happens if you're
attempting to unit test code that links against Growl;
@executable_path will be /Developer/Tools/, and @loader_path will be
your .octest bundle. Thus, the unit tests will fail to load unless you
happen to have Growl.framework in either /Developer/Frameworks/
(unlikely) or in one of the system-wide fallback locations.

Basically, @loader_path is almost always the right thing to use unless
you need to support 10.3 or earlier.

[Peter Hosey]

On Feb 8, 2010, at 22:35:50, BJ Homer wrote:
> If you link to Growl in a prefPane, @executable_path refers to "/

> Applications/System Preferences.app/Contents/MacOS/". @loader_path
> refers to "/Library/Preference Panes/MyPane.prefPane/Contents/MacOS/".

On the other hand, embedding Cocoa frameworks into plug-ins—including
preference panes—will set you up for trouble: If any two plug-ins, or
any plug-in and the host app, both use the same framework, they'll
collide. This won't cause any obvious problem unless they're different
versions, in which case, one of the two clients is not using the
version it expects to use.

The ClickToFlash developers can tell you all about this, as both
ClickToFlash (WebKit plug-in) and the WebKit nightly-build launcher
(host application) use Sparkle.

> The same thing happens if you're attempting to unit test code that
> links against Growl; @executable_path will be /Developer/Tools/, and
> @loader_path will be your .octest bundle. Thus, the unit tests will
> fail to load unless you happen to have Growl.framework in either /

> Developer/Frameworks/ (unlikely) or in one of the system-wide
> fallback locations.

True. I suppose that, for that alone, it's worth bringing this patch
in. I'll do it tomorrow.

[Nicholas Layne]