I am trying to build a minimal easily transportable Ruby without relying on external projects, just for my own learning process.
I am using otool -L ruby to determine what libraries the Ruby binary is dynamically linking against as I am trying to minimize it.
Yesterday when i built Ruby it only dynamically linked against 3 libraries, however today when i build Ruby it is linking against 13. I have no idea what has changed between yesterday and today but I am thoroughly confused -- especially as many of the libraries it is linking against existed prior to yesterday's compilation.
On Yesterday's Ruby executable the result of otool -L was:
otool -L ruby
ruby:
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1349.8.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 489.0.0)
But today it is:
otool -L ./ruby
./ruby:
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1349.8.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/opt/openssl/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
/usr/lib/libffi.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/opt/gdbm/lib/libgdbm.4.dylib (compatibility version 5.0.0, current version 5.0.0)
/usr/lib/libutil.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libedit.3.dylib (compatibility version 2.0.0, current version 3.0.0)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 489.0.0)
Does anyone know what is going on?
I am compiling Ruby 2.4.2 like so:
X="-arch i386 -mmacosx-version-min=10.5"
CFLAGS="$X" CXXFLAGS="$X" LDFLAGS="$X" ./configure --prefix=/tmp/ruby-deploy --with-openssl-dir=$(brew --prefix openssl) --disable-install-doc --without-gmp
The answer to this was that I had also run:
CFLAGS="$X" CXXFLAGS="$X" LDFLAGS="$X" ./configure --prefix=/tmp/ruby-deploy --with-openssl-dir=$(brew --prefix openssl) --with-static-linked-ext --disable-install-doc --without-gmp
at one point -- note the --with-static-linked-ext. This resulted in the other dynamically linked libs.
However because i had subsequently run ./configure again WITHOUT that option i assumed it would have reset the configuration, but it didn't.
I discovered the problem by wiping out the Ruby source folder and re-fetching from github. Running the initial ./configure (excluding the --with-static-linked-ext resolved the issue!
Related
So I'm porting a game from Linux to OS X and having successfully compiled and linked it, I'm now running up against problems starting it – the dynamic linker can't find the libs.
Here's the otool -L output:
./foo:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
#rpath/SDL2.framework/Versions/A/SDL2 (compatibility version 1.0.0, current version 3.1.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 59.0.0)
/usr/lib/libGLEW.1.10.0.dylib (compatibility version 1.10.0, current version 1.10.0)
/usr/lib/libtheoradec.1.dylib (compatibility version 3.0.0, current version 3.4.0)
/usr/lib/libtheora.0.dylib (compatibility version 4.0.0, current version 4.10.0)
/usr/local/lib/libvorbis.0.dylib (compatibility version 5.0.0, current version 5.7.0)
/usr/local/lib/libogg.0.dylib (compatibility version 9.0.0, current version 9.2.0)
#loader_path/libsteam_api.dylib (compatibility version 1.0.0, current version 1.0.0)
/Users/macosx/some/path/to/code/openal-soft-1.16.0/build/libopenal.1.dylib (compatibility version 1.0.0, current version 1.16.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
The thing is, some of those paths are plain wrong. For instance, neither GLEW nor Ogg/Vorbis/Theora exist in /usr/…, and for whatever reason the path to OpenAL Soft is burnt in as an absolute one to where it was built.
Still, by setting DYLD_LIBRARY_PATH correctly, I can get the game to start. However, for multiple reasons I'd prefer not to embed my system's absolute paths within the binary.
What's going on here? Is there a way to force relative paths (that's the #loader_path thing, I presume?) on libraries of my choice? Is there documentation on the matter available?
Just as #trojanfoe suggested – this works:
install_name_tool -change <from> <to> <executable>
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)
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
I'm trying to run a binary executable built for 10.7 (ISCAgent in the below example) on Mac OS X 10.6.8.
The problem with the binary is it depends on /usr/lib/libcurl.4.dylib
with compatibility version of 7.0.0, while I only have version 6.0.0 installed:
$ otool -L ISCAgent
ISCAgent:
#executable_path/libsslserver.dylib (compatibility version 0.0.0, current version 0.0.0)
#executable_path/libssl.dylib (compatibility version 1.0.0, current version 1.0.0)
#executable_path/libcrypto.dylib (compatibility version 1.0.0, current version 1.0.0)
#executable_path/libcachecom.dylib (compatibility version 0.0.0, current version 0.0.0)
#executable_path/libxerces-c-3.1.dylib (compatibility version 0.0.0, current version 0.0.0)
#executable_path/libicuuc.40.dylib (compatibility version 40.0.0, current version 40.0.0)
#executable_path/libicudata.40.dylib (compatibility version 40.0.0, current version 40.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)
$ otool -L libxerces-c-3.1.dylib
libxerces-c-3.1.dylib:
#executable_path/libxerces-c-3.1.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 7.0.0)
#executable_path/libicuuc.40.dylib (compatibility version 40.0.0, current version 40.0.0)
#executable_path/libicudata.40.dylib (compatibility version 40.0.0, current version 40.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
$ otool -L /usr/lib/libcurl.4.dylib
/usr/lib/libcurl.4.dylib:
/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/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
/System/Library/Frameworks/LDAP.framework/Versions/A/LDAP (compatibility version 1.0.0, current version 2.2.0)
/System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos (compatibility version 5.0.0, current version 5.0.0)
/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 41.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
Currently, I've just replaced libxerces-c-3.1.dylib shipped with the executable with one I built myself on my Snow Leopard, and everything seems to work.
I would like to know what my other options are, however.
Particularly:
How can I (I'm pretty sure I can't, but still) have different versions of libcurl.4.dylib with different compatibility version values in the same /usr/lib directory? I'm confused a bit here -- if code contract (API) and/or ABI changes, the version number in the library file name should also be increased, shouldn't it? If, on the other hand, we have a compatibility version mechanism, what the original version number present in the file name is good for?
How can I affect the hard-coded library paths in a 3rd-party shared object? I have a libcurl.4.dylib (from MacPorts, compatibility version 8.0.0) residing under /opt/local/lib, but exporting a proper DYLD_LIBRARY_PATH doesn't help -- libxerces-c-3.1.dylib always picks libcurl.4.dylib from /usr/lib.
I have a library built on OSX 10.6. It runs fine with apps on that version of MacOS. On OSX 10.7 it doesn't run right because it can't find all its dependencies properly, and I suspect it has something to with it thinking that it is linked to itself. Why would screens.so show when I run "otool -L" on screens.so? Is it something that I should remove, and if so, how?
screens.so:
screens.so (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
/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 136.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 12.0.0)
/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime (compatibility version 1.0.0, current version 1327.73.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libwx_macud-2.8.0.dylib (compatibility version 2.6.0, current version 2.8.4)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 34.0.0)
The output is just fine - the first line is merely the ID string of the dynamic library, it shows you what will be used at link time to embed into the executable. For example:
$ otool -L /usr/lib/libz.dylib
/usr/lib/libz.dylib:
/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 159.0.0)
this shows you that linking -lz will result in /usr/lib/libz.1.dylib load command in the binary.
But back to your problem -- it has nothing to do with the first line, it has to do with this line:
/usr/lib/libwx_macud-2.8.0.dylib (compatibility version 2.6.0, current version 2.8.4)
which is linking a library that doesn't exist in Lion - are you sure you need it?