For a reason I don't understand some of the libraries of my binary are statically linked while others have an rpath.
$ otool -L binary
binary:
/usr/local/lib/libtest-1.2.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
/opt/homebrew/opt/openblas/lib/libopenblas.0.dylib (compatibility version 0.0.0, current version 0.0.0)
#rpath/libtorch.dylib (compatibility version 0.0.0, current version 0.0.0)
#rpath/libtorch_cpu.dylib (compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1858.112.0)
/System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL (compatibility version 1.0.0, current version 1.0.0)
How can I force my libtorch libraries for example to be statically linked without using DYLD_LIBRARY_PATH (which can't be overridden without changing some security settings on Mac)?
Thank you.
Related
Checking the first two lines of the output of otool -L /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO shows that the library is apparently linked against itself. Is there a reason for that? Why does that even make sense?
/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO:
/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 600.0.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 48.0.0)
/System/Library/PrivateFrameworks/AppleVPA.framework/Versions/A/AppleVPA (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1252.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1255.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 728.4.0)
/System/Library/PrivateFrameworks/AppleJPEG.framework/Versions/A/AppleJPEG (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)
The first line of the output from otool -L is just the path of the file it's operating on, as passed on the command line.
The second line (the first indented one) is not a dependency. It's showing the install name of the library. In other words, it's showing the value of the LC_ID_DYLIB load command, not any of the LC_LOAD[_WEAK]_DYLIB commands.
From the otool man page (which isn't in Apple's online reference library for some reason):
-L Display the names and version numbers of the shared libraries
that the object file uses, as well as the shared library ID if
the file is a shared library.
Note: "as well as the shared library ID if the file is a shared library".
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 C++ application that depends on several .dylib; Amongst them, libproj and PythonQt.
I pre-built these libs in separate directories.
2 (related) questions :
The executable finds the full path of the libproj.dylib, although it's not in the path, not in DYLD_LIBRARY_PATH, not in QtCreator's configuration. How ?
The executable does NOT find PythonQt, although it's linked exactly the same way. I have to manually add the right path in DYLD_LIBRARY_PATH. Why ?
It's probably related to the fact that there is a .la and a .dylib for libproj, but only a .dylib for PythonQt; but I'm not sure and I don't understand the relation.
Sample output of otool :
/Users/arnaud/Projects/myprojectname/external/proj-4.8.0/bin_mac64_gcc421_release/lib/libproj.0.dylib (compatibility version 8.0.0, current version 8.0.0)
( so it finds libproj correctly, even in another directory )
libPythonQt.1.dylib (compatibility version 1.0.0, current version 1.0.0)
(... but not libPythonQt, which is in a similar directory )
/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0)
QtOpenGL.framework/Versions/4/QtOpenGL (compatibility version 4.8.0, current version 4.8.3)
QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.3)
QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.3)
QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.8.0, current version 4.8.3)
/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/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 697.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
I have an application that I built myself. However, it says it needs X11 although it shouldn't . How can I easily (without expanding ldd over and over) figure out which dependency caused X11?
If it helps, here is the output of otool -L:
libopencv_core.2.3.dylib (compatibility version 2.3.0, current version 2.3.1)
libopencv_imgproc.2.3.dylib (compatibility version 2.3.0, current version 2.3.1)
libopencv_features2d.2.3.dylib (compatibility version 2.3.0, current version 2.3.1)
/opt/local/lib/libboost_serialization-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/local/lib/libboost_iostreams-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/local/lib/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/local/lib/libboost_filesystem-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/local/lib/libboost_unit_test_framework-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.16.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
thanks and best wishes
UPDATE
it is a unit testing executable for a computer vision module. And it is written in C++, built using cmake.
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?