CocoaLibSpotify - Library not loaded - xcode

I've created a simple mac app that uses the Cocoa wrapper for libspotify.
When I export the project as an Application and try to run it, it crashes immediately.
Crash report:
Application Specific Information:
dyld: launch, loading dependent libraries
Dyld Error Message:
Library not loaded: #rpath/CocoaLibSpotify.framework/Versions/A/CocoaLibSpotify
Referenced from: /Users/USER/Desktop/Wunderkiste.app/Contents/MacOS/Wunderkiste
Reason: image not found
otool output:
$ otool -L ~/Desktop/Wunderkiste.app/Contents/MacOS/Wunderkiste
#rpath/CocoaLibSpotify.framework/Versions/A/CocoaLibSpotify (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 20.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1056.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1265.0.0)
/System/Library/Frameworks/CoreData.framework/Versions/A/CoreData (compatibility version 1.0.0, current version 481.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.11.0)
Project - Build Phases
Any ideas?

The Runtime Search Paths build setting in your project needs to contain #loader_path/../Frameworks to tell the dynamic linker where to find CocoaLibSpotify at runtime.
See Linking and Install Names by Mike Ash for a detailed discussion.

Related

I am having trouble getting Phusion Passenger to run on OS X Yosemite

I recently upgraded my MacBook to Yosemite, and now passenger no longer seems to work. Every time I try to restart Apache, I get this error in the logs:
[ 2014-10-19 17:08:51.6913 9735/0x7fff7b970300 agents/HelperAgent/Main.cpp:650 ]: PassengerHelperAgent online, listening at unix:/tmp/passenger.1.0.9726/generation-0/request
dyld: Library not loaded: /opt/local/lib/libcurl.4.dylib
Referenced from: /Users/barry.flinn/.rvm/gems/ruby-2.0.0-p353#sermo/gems/passenger-4.0.53/buildout/agents/PassengerLoggingAgent
Reason: Incompatible library version: PassengerLoggingAgent requires version 8.0.0 or later, but libcurl.4.dylib provides version 7.0.0
When I run otool -L /opt/local/lib/libcurl.4.dylib, I get:
/opt/local/lib/libcurl.4.dylib:
/opt/local/lib/libcurl.4.dylib (compatibility version 8.0.0, current version 8.0.0)
/opt/local/lib/libidn.11.dylib (compatibility version 18.0.0, current version 18.12.0)
/opt/local/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
However, the system version /usr/lib/libcurl.4.dylib gives:
/usr/lib/libcurl.4.dylib:
/usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 8.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 57031.1.27)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1151.14.0)
/System/Library/Frameworks/LDAP.framework/Versions/A/LDAP (compatibility version 1.0.0, current version 2.4.0)
/System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos (compatibility version 5.0.0, current version 6.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
As near as I can tell, even though I built mod_passenger against /opt/local/lib/libcurl.4.dylib, it is still trying to run using the lib at /usr/lib/libcurl.4.dylib. I am stuck trying to figure out why.
Please have a look here. I had the same problem after upgrading to Yosemite and the solution for me was to unset DYLD_LIBRARY_PATH (which is one of the solutions suggested by macports)

OS X dlopen can't find framework - Image Not Found

I'm trying to add Google Breakpad (some external framework) support to my application. I have done all the required steps, but when I try to load my application using dlopen, I get this error:
(char *) error = 0x0000000100200175 "dlopen(/Users/user/MyApp.app/Contents/MacOS/MyApp, 1):
Library not loaded: #executable_path/../Frameworks/Breakpad.framework/Versions/A/Breakpad\n
Referenced from: /Users/user/MyApp.app/Contents/MacOS/MyApp\n
Reason: image not found"
I checked and the Breakpad file does indeed exist in the relative path (to the MyApp file).
Here's the otool -L on the MyApp file (notice the #executable_path):
Users-Mac:MacOS user$ otool -L MyApp
MyApp:
/usr/lib/libcurl.4.dylib (compatibility version 6.0.0, current version 6.1.0)
/usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
/usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 9.6.0)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
#executable_path/../Frameworks/Breakpad.framework/Versions/A/Breakpad (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 152.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 15.0.0)
/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/CoreAudioKit.framework/Versions/A/CoreAudioKit (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/CoreMIDI.framework/Versions/A/CoreMIDI (compatibility version 1.0.0, current version 49.0.0)
/System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.6.3)
/System/Library/Frameworks/WebKit.framework/Versions/A/WebKit (compatibility version 1.0.0, current version 533.21.1)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.43.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1038.36.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 38.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 44.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 751.62.0)
Anyone has a clue?
Follow this steps, It may work:
go to Target then press Build Phase
left top of this page you will find + symbol, press this symbol.
press New Copy Files Build Phase
expand copy file then Drag you framework and drop in this section.
Change the Destination to frameworks
Hope it will Work
Well, it turns out it was a problem when using dynamic libraries and compiling for OS X 10.6.
The #executable_path doesn't get updated after the dynamic load and thus the LOADED binary is looking for its dependencies relative to the LOADING binary.
I ended up recompiling my framework, Breakpad, and using #loader_path instead of #executable_path, and now everything works just fine.
More info here:
dylib #executable_path path issue in a plug-in bundle

Qt problems building on Mac OS X 10.7.5 with Qt 4.8.1 using QSerialPort

So I have a project that I have been working on. Currently I am able to build it in Linux and Windows without too much trouble. I am having some issues on Mac, however.
I'm using Mac OS X 10.7.5, with Qt 4.8.1.
I installed the libraries for QSerialPort since those are not included in Qt4. It looks like they installed correctly. My /qt/4.8.1/gcc/lib folder now includes:
libQtSerialPort_debug.1.0.0.dylib
libQtSerialPort_debug.1.0.dylib
libQtSerialPort_debug.1.dylib
libQtSerialPort_debug.dylib
libQtSerialPort_debug.prl
When I try to build the project this is what I get:
Starting /Users/ken/esu_2.x/esu/esu.app/Contents/MacOS/esu...
dyld: Library not loaded: libQtSerialPort_debug.1.dylib
Referenced from: /Users/ken/esu_2.x/esu/esu.app/Contents/MacOS/esu
Reason: image not found
The program has unexpectedly finished.
/Users/ken/esu_2.x/esu/esu.app/Contents/MacOS/esu exited with code 0
Edit:
apples-MacBook-Pro:macOs ken$ otool -L esu
esu:
libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
libQtSerialPort_debug.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/Users/ken/QtSDK/Desktop/Qt/4.8.1/gcc/lib/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.1)
/Users/ken/QtSDK/Desktop/Qt/4.8.1/gcc/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.1)
/Users/ken/QtSDK/Desktop/Qt/4.8.1/gcc/lib/QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.8.0, current version 4.8.1)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1094.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
Moved QtSerialPort libraries to /usr/lib. It works now.

Deploy Qt C++11 app on Mac OS with older libstdc++

When I try to deploy my app on another machine, it fails with dyld/unresolved symbol errors. (Qt static release build, btw.) When I put libstdc++ in the bundle (along with libSystem.B and libobjc.A) and run install_name_tool appropriately, I get new linker errors, for libraries upon which these libraries depend. E.g., libc++.1. I'm really hoping I don't have to manually go through and run install_name_tool on every single library and its children. (Or write my own script, which I don't know how to do.) Is there a better way? This pair (one, two) of questions goes after essentially this question but didn't quite get as far as I did and wasn't resolved in any case.
Here is where I'm at with otool:
$otool -L my_app
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
(compatibility version 1.0.0, current version 41.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
(compatibility version 150.0.0, current version 635.21.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security
(compatibility version 1.0.0, current version 55148.6.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
(compatibility version 2.0.0, current version 153.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
(compatibility version 45.0.0, current version 1138.51.0)
#executable_path/libz.1.dylib (compatibility version 1.0.0, current
version 1.2.5) #executable_path//libstdc++.6.dylib
(compatibility version 7.0.0, current version 7.17.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1094.0.0) /opt/local/lib/gcc47/libgcc_s.1.dylib
(compatibility version 1.0.0, current version 1.0.0)
#executable_path/libSystem.B.dylib (compatibility version 1.0.0,
current version 159.1.0) #executable_path/libobjc.A.dylib
(compatibility version 1.0.0, current version 228.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
(compatibility version 1.0.0, current version 53.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
(compatibility version 300.0.0, current version 833.25.0)
Edit: Here's the initial error message I got, which after making the first round of changes disappeared, to be replaced by a similar message regarding libc++.1:
Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes:
0x0000000000000002, 0x0000000000000000 Crashed Thread: 0
Dyld Error Message: Symbol not found: __ZNSt8__detail12__prime_listE
Referenced from:
/Users/nfoley/Downloads/WaveSorter-mac-1.0.1-static/WaveSorter.app/Contents/MacOS/WaveSorter
Expected in: /usr/lib/libstdc++.6.dylib

dyld: Library not loaded: libboost_system.dylib

Yet another dyld: Library not loaded dylib problem..
I've got a dylib (libboost_system.dylib) compiled from the Boost sources,
then used install-name-tool to prepare it for inclusion in the Frameworks folder of my app bundle like so:
install_name_tool -id #executable_path
/../Frameworks/
libboost_system.dylib libboost_system.dylib
Verified with otool:
$> otool -L libboost_system.dylib
/Users/TesterCodeSandbox/OgreSDK
/BOOST_DYLIBS/libboost_system.dylib:
#executable_path/../Frameworks
/libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
Now added to the Xcode project, linked against the app and copied to the Frameworks folder.
But when checking the built app with otool -L it's still referring to the original (i.e. 'non-relocated') dylib:
OgreTest-ekeeqmnyciddaxbzyrehtcoijcki/Build
/Products/Debug/OgreTest.app/Contents/MacOS/OgreTest:
#executable_path/../Plugins
/RenderSystem_GL.dylib (compatibility version 0.0.0, current version 1.8.0)
/System/Library/Frameworks/Cocoa.framework/
Versions/A/Cocoa (compatibility version 1.0.0, current version 15.0.0)
#executable_path/../Frameworks/Ogre.framework/
Versions/1.8.0/Ogre (compatibility version 0.0.0, current version 1.8.0)
#executable_path/../Frameworks/Cg.framework
/Cg (compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A
/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A
/Carbon (compatibility version 2.0.0, current version 152.0.0)
libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libstdc++.6.dylib
(compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib
(compatibility version 1.0.0, current version 125.2.11)
/usr/lib/libobjc.A.dylib
(compatibility version 1.0.0, current version 227.0.0)
/System/Library/Frameworks/CoreFoundation.framework
/Versions/A/CoreFoundation
(compatibility version 150.0.0, current version 550.43.0)
/System/Library/Frameworks/AppKit.framework
/Versions/C/AppKit
(compatibility version 45.0.0, current version 1038.36.0)
And the app fails to start with the 'dyld: Library not loaded: libboost_system.dylib' error. Any ideas?
Note 1
Now it does work if I also post-process my app's binary with install_name_tool, i.e.:
install_name_tool -change libboost_system.dylib #executable_path/../Frameworks/libboost_system.dylib TestApp
Am I missing some Xcode option to force the compiler to change the dylib location in my app automatically as part of the build?
Surely invoking install_name_tool manually for the application consuming the dylib (i.e. one of potentially many) can just be a work-around for something I've screwed up when configuring the (application) project....

Resources