I am trying to add the liboauth.dylib to my xcode project (c++). I have configured and made the library, which is now sitting in my /usr/local/lib which now has:
liboauth.0.dylib
liboauth.dylib <- a link to liboauth.0.dylib
liboauth.li
liboauth.a
with the header in usr/local/include. Seems fine.
I have included this in my xcode by adding the path /usr/local/lib/liboauth.dylib to the Other Linker Flags section, and usr/local/include/ to the Header Search Paths.
I have also included the same in the Library Search Paths.
This builds fine on my system. However if I take the resulting .app to another (osx) computer it gives the error the /usr/local/liboauth.0.dylib (I get this by opening the .app and running the unix executable).
Shouldn't the linker have included the liboauth dylib when built? And then it shouldn't be a problem when going to a different computer?
If the answer is no, then how would I go about included the liboauth.dylib into the .app, so it can run on any computer (running osx)?
Here is the specific error:
Library not loaded: /usr/local/lib/liboauth.0.dylib
Referenced from: /Users/scratch/gameTest.app/Contents/MacOS/gameTest
Reason: image not found
Edit: I have found the problem! Using the otool -l command on the liboauth.0.dylib I found this:
Load command 3
cmd LC_ID_DYLIB
cmdsize 56
name /usr/local/lib/liboauth.0.dylib (offset 24)
time stamp 1 Thu Jan 1 12:00:01 1970
current version 9.1.0
compatibility version 9.0.0
Can someone help me to figure out how to change this? I think it has something to do with the install_name_tool but I do not know how to go about it properly.
Are both system the same? 32-bit/64-bit, Snow Leopard vs. Leopard.
I can see how the libraries would be different and that error could be produced if that was the case.
If they are the same, it is possible that you are setting the linker flags in your project settings and it is being overridden by your target settings.
Related
As part of a research project I'm trying to use clang 6.0.1 with Xcode 9.4.1. I've built and installed clang in a custom location (/opt/llvm-6_0_1/clang). I wrote a simple xcplugin compiler specification to integrate my clang version with Xcode.
Now I can open projects in Xcode, select my proxy compiler and use it to build instead of Apple's default clang.
There were some minor additions that I had to make to the xcplugin's xcspec file to get this to work that probably won't be interesting to most people, so I won't provide the details here unless asked.
This all works with most of the projects I've played with, but I'm running into an odd problem where an implicitly linked static library cannot be found by my copy of clang. Specifically I get this error:
ld: file not found: /opt/llvm-6_0_1/clang/Toolchains/LLVM6.0.1.xctoolchain/usr/lib/arc/libarclite_macosx.a
clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation)
Note that the libarclite_macosx.a file is not explicitly included by the Xcode project. I figured it must be implicitly included, perhaps because this project enables ARC?
After pouring over the Xcode generated link command line (it's complex) I decided to look at the MyProject__dependency_info.dat file, which is passed in via the -dependency_info option. Apparently this data file (the path is defined as env var LD_DEPENDENCY_INFO_FILE) is created during the linking process, not as an input to the linker. Perhaps it exists because of a hack workaround using symlinks that I used to get a link to work (described at the end).
In any case the format appears to be binary, but I was able to see a text reference to libarclite_macosx.a in the file:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/arc/libarclite_macosx.a
After enabling the -Xlinker -v option I could see that my built clang was not searching the default toolchain lib or arc paths so I added them:
-L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib
-L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/arc
Now I can see the search paths in the verbose output, but clang still cannot find the library:
Library search paths:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/arc
I've tried adding the paths to the frameworks search paths. I also tried defining the various link path env vars. Nothing has worked.
To try to get a sense of what clang is actually doing, I used fs_usage while getting the link error:
sudo fs_usage -e -w -f filesys | grep "lib/arc"
14:11:00.461965 stat64 [ 2] /opt/llvm-6_0_1/clang/Toolchains/LLVM6.0.1.xctoolchain/usr/lib/arc>>>>>>>>>>>>>>>>>>>>>> 0.000006 ld.1421614
14:11:00.461968 stat64 [ 2] /opt/llvm-6_0_1/clang/Toolchains/LLVM6.0.1.xctoolchain/usr/lib/arc>>>>>>>>>>>>>>>>>>>>>> 0.000002 ld.1421614
Clearly clang really wants to look for this file in the installed location, not the location indicated in the -dependency_info, nor in the search paths that I'm providing.
At this stage the only way I can get a build to work is to add a symlink to Xcode's "arc" directory to my installed clang lib directory. That "works", but is fragile and nasty.
Any thoughts as to how how I can get clang find the static library where it actually lives?
I am trying to write a simple application with GLFW on Linux. Right now the main file (the only file) is basically just a few lines of code to make sure the dynamic library linked correctly. Here it is:
#include <GLFW/glfw3.h>
#include <iostream>
int main()
{
glfwInit();
std::cout << "It works this far!" << std::endl;
glfwTerminate();
}
The include files are stored in a directory labelled "include" and the library files are stored in a directory labelled "lib". As of right now, I am compiling the program with the following line:
g++ -Wl,-Rlib -Iinclude -Llib test.cpp -o test -lglfw.3.2
It compiles and links just fine, but when I try to execute it, I get the following error:
./test: error while loading shared libraries: libglfw.so.3: cannot open shared object file: No such file or directory
Now, before you rush to downvote this question into oblivion and mark it as a duplicate, at least allow me to explain why I believe my question is different enough to not be a duplicate. I already attempted the solutions that the other questions presented, but it was unsuccessful. As you can see, I tried setting the path to the library during linking with the -Wl,-Rlib tag. I also tried setting LD_LIBRARY_PATH to point to the location of my libraries (the 'lib' folder), but it still threw the same error. (It didn't matter if the path was relative or absolute.)
So, the next thing I tried was running the ldd command on the executable. I got some other dependencies that were working just fine, but importantly, I got this:
libglfw.so.3 => not found
For some reason, it insists on looking for libglfw.so.3. It will not have it any other way. Upon renaming the library from libglfw.3.2.so to libglfw.so.3, the program executed just fine and printed It works this far! as if there were no problems at all.
Why would this happen?
For some reason, it insists on looking for libglfw.so.3. ... Upon renaming the library from libglfw.3.2.so to libglfw.so.3 ...
The ELF executables contain the exact name of the dynamic libraries used.
If the executable contains the library name "libglfw.so.3" the file must be named exactly like this.
The file naming scheme is intentionally done in a way that not the "full" version is coded into the file name: This way a later version ("libglfw.so.3.15") will work with the executable.
Normally there should be a symbolic link to the latest version of the library installed:
libglfw.so.3 -> libglfw.so.3.2
This symbolic link seems to be missing on your computer. I would say that this is an installation problem!
EDIT
The question could be: Why is the file name stored in the executable file not libglfw.3.2.so but libglfw.so.3?
The answer has to do with the backward compatibility when a new version of a library is installed:
Normally you would use the switch -lglfw and a symbolic link named libglfw.so is looked up.
If you stored the file name libglfw.so in the executable file and a new, incompatible version if this library (libglfw.so.4) is installed you would have no chance to get the program running by having both versions of the library installed.
To enable backward compatibility by having both versions of the library installed the "real" symbolic link name of the library (libglfw.so.3) must be stored in the executable file.
Therefore the "expected" file name of a library is stored in the library itself: Inside the file libglfw.so.3.2 you'll find some information that the file expects itself to be stored as libglfw.so.3.
The linker will use this information about the file name because it assumes that the library name given in the linker switch (-lglfw) is less "precise" than the name stored in the library itself.
For some reason, it insists on looking for libglfw.so.3. It will not have it any other way.
This is the Linux convention for shared libraries which is described here among other places. For Linux libfoo.so.x.y.z is considered to have the same ABI as libfoo.so.x. Usually when shared libraries are installed (e.g. via rpm, dpkg, etc.) there's an invocation of ldconfig that happens so that the just installed libraries have a symlink following the convention installed that references the library. Also these libs (if installed to a "trusted location"), are added to a linker cache for performance reasons.
It compiles and links just fine, but when I try to execute it, I get the following error:
./test: error while loading shared libraries: libglfw.so.3: cannot open shared object file: No such file or directory
libglfw.so.3 isn't on ld-linux.so's path.
As you can see, I tried setting the path to the library during linking with the -Wl,-Rlib
Still won't find it -- libglfw.so.3 isn't on ld-linux.so's path. You can add it by doing something like:
ldconfig -n /path/to/lib
Which should output the requisite libglfw.so.3 symlink for your lib.
IIRC setting the rpath might require a full path.
I also tried setting LD_LIBRARY_PATH to point to the location of my libraries
Again, libglfw.so.3 isn't on ld-linux.so's path.
In Ubuntu 14.04, I have downloaded some source code which comes with a makefile. I have then run "make" on it to compile, which builds an executable. When executing this file, I receive the following error:
./mt_test: error while loading shared libraries: libcudart.so.7.0: cannot open shared object file: No such file or directory
Now, the file libcudart.so.7.0 is located in the directory /usr/local/cuda-7.0/lib64. But in my .bashrc file, I have the line: export LD_LIBRARY_PATH=/usr/local/cuda-7.0/lib64:$LD_LIBRARY_PATH. Furthermore, if I run echo $LD_LIBRARY_PATH from the terminal, one of the entries is this path. There are no other copies of libcudart.so.7.0 elsewhere on my system.
Is there any reason why the executable might not be able find this library, even though its directory is one of the search directories?
Strangely, this error has only happened since installing Matlab on my system. There is now a file called libcudart.so.6.5 located at /usr/local/MATLAB/R2015a/bin/glnxa64, but this path is not part of LD_LIBRARY_PATH.
As MadScientist probably correctly guessed, this is likely a 32 vs. 64-bit mismatch. Run the following command:
file -L ./mt_test /usr/local/cuda-7.0/lib64/libcudart.so.7.0
The command should report either ELF 32-bit LSB ..., or ELF 64-bit LSB ... for both files. If one of the files is 32-bit, and the other 64-bit, then they are not compatible.
You can gain further insight into where the dynamic linker is searching for libcudart.so.7.0 by running the following command:
LD_DEBUG=files,libs ./mt_test
I am getting the following issue:
/Users/luke/Desktop/trainHOG/trainhog ; exit;
dyld: Library not loaded: lib/libopencv_core.3.0.dylib
Referenced from: /Users/luke/Desktop/trainHOG/trainhog
Reason: image not found
Trace/BPT trap: 5
logout
I am using a Mac running OSX v10.9.5 with openCV 3.0 alpha.
The library in question is definitely in the folder. I have tried deleting it and pasting it back into the folder, I have completely deleted and reinstalled openCV and macports, and I have tried the export DYLD_LIBRARY_PATH = "path to dynamic libs here..", but nothing has worked. I have even rebooted my computer on several occasions!
Does anyone have any further suggestions? I am out of ideas
OpenCV 3.3
OSX 10.13
fist have a test, you can use clang++ -o a -I ./include -L ./lib
-lopencv_core.your.version
then you can generate executable file a ,run it ,if have the error massage.
you will find the error reason cannot find the lib when you are link.
if you want to solve error on terminal
you can use export DYLD_LIBRARY_PATH=your/lib:$DYLD_LIBRARY_PATH
if you want to solve error on Xcode
in build page , go to "Runpath Search Paths"
add you lib path
If you use
export DYLD_LIBRARY_PATH = "path to dynamic libs here.."
is it applied to the environment of your program?
You can check the environment variables of a running process with
ps -p <pid> -wwwE
Does this help?
If you are having this Problem:
dyld: Library not loaded: *.dylib ... Reason: no suitable image found.
Means your *.dylib files are not signed with your Apple iD develop account, and
There is two ways to solve that:
1) The right way: Code sign all your files with errors with this command:
codesign -f -s "Mac Developer: YOURDEVELOPEREMAIL" /usr/local/opt/*/lib/*.dylib
2) The temporary way(until you don't deploy to App Store): Inside Xcode, go to:
[YourProjectFile] --> [YourTargetFile] --> "Signing & Capabilities" --> and Enable "Disable Library Validation"
Done :D
Seems to be a bug in some versions of OpenCV's CMake configuration files which incorrectly record relative paths in the installed dylibs, reasonably easy to fix.
This answer on answers.opencv.org addresses the issue. In OpenCVModule.cmake and every instance of CMakeLists.txt replace INSTALL_NAME_DIR lib with INSTALL_NAME_DIR ${CMAKE_INSTALL_PREFIX}/lib.
I'm working with Awesomium in linux, the SDK only provides a shared library: libawesomium-1.6.3.so. Some libraries on my machine have lower versions than what Awesomium requires:
$ ldd libawesomium-1.6.3.so
libawesomium-1.6.3.so: /usr/lib/libjpeg.so.62: no version information available
(required by libawesomium-1.6.3.so
So when I'm compiling with g++ -lawesomium-1.6.3 ... I will get errors like below:
libawesomium-1.6.3.so: undefined reference to 'jpeg_finish_output#LIBJPEG_6.2'
I know updating the jpeg library will solve the issue. But I don't have the root permission in the linux machine.
So I'm wondering whether there is a way to specify a relative path to a new libjpeg.so for awesomium-1.6.3.so to use.
Update (cannot comment on the answers):
I tried to add the -L/path/to/new/libjpeg.8 -ljpeg flags, the following warning shows up:
/usr/bin/ld: warning: libjpeg.so.62, needed by libawesomium-1.6.3.so, may conflict
with libjpeg.so.8
And the compiling still fails. I think the issue is, libjpeg is referenced indirectly by libawesomium, not directly by my code.
Use the -L option. But use it before -ljpeg!
When compiling, use -L option as fge said. But to run it, you will have to add the path to your library to LD_LIBRARY_PATH environment variable (see ยง3.3.1 here).