"image not found" when building from head

[gnachman]

I'm trying to upgrade to the latest Sparkle, but I get this error when I try to run my program:

dyld: Library not loaded: @rpath/Sparkle.framework/Versions/A/Sparkle
Referenced from: /Users/gnachman/SparkleTest/Build/Debug/SparkleTest.app/Contents/MacOS/SparkleTest
Reason: image not found

Steps to reproduce:

1. Build the Release version of the Distribution target of Sparkle
2. Create a new Xcode project. Select Cocoa Application.
3. Unzip the Sparkle bz2 in the new project's folder
4. Rick click on Frameworks, select Add files
5. Select Sparkle.framework
6. Build and run

I also tried adding Sparkle.framework to the Copy Bundle Resources phase, as well as adding a new Copy Files phase with the Frameworks destination.

Sparkle 1.5b did not use @rpath. otool -L on a binary linked with 1.5b shows:
@loader_path/../Frameworks/Sparkle.framework/Versions/A/Sparkle (compatibility version 1.5.0, current version 1.5.0)

while otool -L on a program linked with the latest shows:

@rpath/Sparkle.framework/Versions/A/Sparkle (compatibility version 1.6.0, current version 1.8.0)

I'm not sure where the @rpath is coming from, but that seems to be problematic.

[jakepetroules]

Because Sparkle now only supports versions of OS X that support @rpath, we use it for maximum flexibility instead of hardcoding a predefined search path.

The correct solution is to add the linker flag -Wl,-rpath,@loader_path/../Frameworks to your application. In Xcode you can use the LD_RUNPATH_SEARCH_PATHS variable to set this. For example, in an xcconfig file:

LD_RUNPATH_SEARCH_PATHS = @loader_path/../Frameworks

Or you can set it in the Xcode GUI, whichever you prefer.

[gnachman]

Thanks, that worked!

[kornelski]

I've just got bitten by this myself.

When running app via cmd-R in Xcode it magically works even without the linker flag, but the .app launched from Finder crashes with "image not loaded". That's a thing that can drive people to insanity.

[ConfusedVorlon]

I'm hitting this problem now with the podspec for 1.10

I can fix it by following the instruction (not in the cocoapods instructions) to add

In Build Settings tab set “Other Linker Flags” to -Wl,-rpath,@loader_path/../Frameworks.

I'm guessing the podspec should be handling this, but if not, then the documentation should list the step.

[sanfords]

1. You can use otool -L Sparkle (inside the framework bundle) to see what the framework's path is.
2. You can change to @rpath to @executable_path/../Frameworks in xcconfig.
3. Then your framework can live in /Frameworks in your app bundle. In this case be sure:
   (a) Build Phases -> Link Binary with Libraries and the Copy Files Frameworks areas are set up.
   (b) You may have to add the path to the framework to your Framework Search Paths in build settings.

This above worked for me for upgrading today. Don't know what will happen tomorrow. ;-)

[jakepetroules]

You can change to @rpath to @executable_path/../Frameworks in xcconfig.

Do not do that. The correct solution is to set

LD_RUNPATH_SEARCH_PATHS = @loader_path/../Frameworks

in your app's build settings (which adds -Wl,-rpath,@loader_path/../Frameworks to your app's Other Linker Flags) as suggested above. You should not change Sparkle.

[sanfords]

Will that affect the other frameworks I'm linking?

[jakepetroules]

Obviously, but that's how you should be linking all frameworks, not just Sparkle.

[sanfords]

I understand @rpath is the new and shiny toy. But your recommendation dismisses backwards compatibility with complex source bases. The reality of budgets and schedules sometimes demand something else. I have no problem with @rpath where the former do not interfere. :-)

[jakepetroules]

@rpath isn't new, it's been part of macOS since 2007. I don't expect you to have any problems.