I'm trying to compile Caffe (http://caffe.berkeleyvision.org/installation.html) and I get the following errors:
/usr/bin/ld: cannot find -lcblas
/usr/bin/ld: cannot find -latlas
However, I have these libraries installed (libatlas).
My LD_LIBRARY_PATH contains the path /usr/lib/atlas-base and it contains the files libcblas.so and libatlas.so (and some other files as well).
Why ld can't find these libraries?
Thanks.
tl;dr: Caffe makefile looks for libblas.so in /usr/lib. If missing, update-alternatives creates a symbolic link /usr/lib/libblas.so to the location where it is installed. Same applies to libcblas.so. LD_LIBRARY_PATH is for runtime, and doesn't have anything to do with this.
LD_LIBRARY_PATH doesn't really help you when compiling. It only provides directories to look for shared libraries when executing programs that rely on them, after they are compiled. Still, when linking during the compilation, the compiler needs to find these shared libraries, and does so by other means than LD_LIBRARY_PATH.
More to the point: if compiling with gcc or clang, the directories in which to look for libraries to link with are provided using the -L flag, and it does not consider the LD_LIBRARY_PATH environment variable.
Common locations for libblas.so are /usr/lib/atlas-base/ and /usr/lib/libblas/. The Makefile for caffe doesn't do anything particular to try and locate these subdirectories, and relies on these libraries being in the default library directory /usr/lib/. Typically a symbolic link /usr/lib/libblas.so exists, and points to the real location of the shared library. For some reason, this wasn't the case in your initial configuration.
When dealing with multiple alternatives for packages, update-alternatives comes in handy. In the case of libblas.so it let's you easily switch between multiple implementations (libblas, openblas) you might have installed, and does so by changing out the symbolic links.
sudo update-alternatives --config libblas.so created this symbolic link when it was missing, which in turn let the compiler find the shared library, solving your problem. This is indicated by the output of the command:
$ sudo update-alternatives --config libblas.so
There is only one alternative in link group libblas.so (providing /usr/lib/libblas.so): /usr/lib/libblas/libblas.so
Nothing to configure.
Same kind of reasoning applies to libcblas.so.
It turns out I had to run
sudo update-alternatives --config libblas.so
sudo update-alternatives --config liblapack.so
and to select libatlas .
I have no idea why,. If anyone can explain this me I will give him the answer.
Thanks.
sudo apt-get install libatlas-base-dev worked for me, it removed both missing dependencies.
See this thread for additional details https://github.com/BVLC/caffe/issues/559
As an addendum to #Ran's answer, Ubuntu in particular has an odd package structure for what's needed with Caffe. I just came across this post in fixing this same issue on my own machine, and here's some help if others are stuck. (Ubuntu 14.04).
libatlas-dev does NOT have libatlas-base-dev as a dependency! Caffe seems to like the libraries from the latter only. Install it.
Then, run the commands suggested by #Ran and select the libraries from the atlas-base directory under /usr/lib. With just libatlas-dev installed, update-alternatives will have the output at the bottom of #swalog's post, but does not actually link an atlas library that caffe seems to approve of! It needs to be the one from atlas-base. Hope this helps!
Related
I work on CentOS 5.5 and my computer used gcc-4.1.2 until now, and under /usr/lib/gcc/x86_64-redhat-linux/ there were 2 indexes: 4.1.1 and 4.1.2. For using some softwares I must update the gcc.
But after I installed gcc-4.7.0 from the downloaded gcc-4.7.0.tar.gz (I did not use yum because when I tried it all servers told me that I had the latest version which was certainly not true, and perhaps this was also caused by the problem I now face with), the /usr/lib/gcc/x86_64-redhat-linux/4.7.0/ was created just like the 4.1.1 and 4.1.2 index, so under /usr/lib/gcc/x86_64-redhat-linux/ there were 3 indexes: 4.1.1, 4.1.2 and 4.7.0. And under /usr/lib/gcc/x86_64-redhat-linux/4.7.0/ there were 6 indexes:
bin include lib lib64 libexex share
It looked like that 4.7.0 was successfully installed but when I ran
gcc --version
the result was still
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I also ran
update-alternatives --install /usr/bin/gcc gcc /usr/lib/gcc/x86_64-redhat-linux/4.7.0 40
to raise the priority of 4.7.0, and when I ran
update-alternatives --config gcc
it said
There is 1 program that provides 'gcc'.
Selection Command
-----------------------------------------------
*+ 1 /usr/lib/gcc/x86_64-redhat-linux/4.7.0
Enter to keep the current selection[+], or type selection number:
And I printed 1, all it looked like that 4.7.0 was selected as the default gcc, but when I ran gcc --version, the result was not changed! Still 4.1.2.
After that I even removed all 4.1.2 gcc and its related programs by rpm -e and deleted the index, but the result of gcc --version became
-bash: gcc: command not found.
It didn’t change when I reinstalled the 4.7.0.
After all, when I looked for the links of /usr/bin/gcc/ I found
/usr/bin/gcc -> /etc/alternatives/gcc
and link of /etc/alternatives/gcc was
/etc/alternatives/gcc -> /usr/lib/gcc/x86_64-redhat-linux/4.7.0
this should be the result of my running the update-alternatives line, so it has worked. It did make the link to 4.7.0. So why didn’t this link call 4.7.0 in the end? I can’t find out.
I even made the direct link to 4.7.0 then:
ln -s /usr/lib/gcc/x86_64-redhat-linux/4.7.0 /usr/bin/gcc
however this still didn’t work.
I am very confused with it. I will be grateful for your help. Thank you very much!
p.s. Thank Basile Starynkevitch very much for noticing me to make these explanations:
I have /usr/bin/ in my PATH, so this should be OK.
I am teached that /usr/bin/gcc/ should be linked to an executable but not index, so the link to 4.7.0 is wrong. But could anyone tell me which executable to link to, or which executable is /usr/bin/ linked to in a common computer? This may very likely lead to the solution to the problem.
I cannot run configure one more time because configure itself requires gcc but now it is not found. So I'm afraid the problem cannot be fixed by that.
Be aware of the PATH variable. You could have some $HOME/bin/ in it.
Restore your system's gcc (so undo all the mess you have done). Then run which gcc and gcc -v to understand what is it exactly.
If you compile GCC from its source code (as distributed by the FSF), choose a recent version, e.g. GCC 8 in fall 2018.
Read carefully about installing GCC. Compile it outside of its source code. Be aware of the many configure options. I suggest to consider configuring it with some --program-suffix option (such as --program-suffix=-8) and then adding symlinks (e.g. $HOME/bin/gcc -> /usr/local/bin/gcc-8) appropriately.
ln -s /usr/lib/gcc/x86_64-redhat-linux/4.7.0 /usr/bin/gcc
it is wrong. Since /usr/lib/gcc/x86_64-redhat-linux/4.7.0/ is some internal directory, and /usr/bin/gcc has to be an executable.
You probably don't need to run update-alternatives, but you do need to add (cleverly) something in a directory mentioned in your PATH
See also this answer to a similar question.
after edits in the question
You need first to clean up the mess you did under /usr/ (in particular in /usr/bin/ which you should never change without your package system). Remove all the things you added under /usr/bin/ and /usr/lib/. Then re-install forcibly and explicitly appropriate system gcc packages (using yum or some other package manager).
I have /usr/bin/ in my PATH, so this should be OK.
Probably not. My recommendation is to have $HOME/bin/ and /usr/local/bin/ early in your PATH (so before /usr/bin/; you might need to edit ~/.bashrc to change your PATH setting) and to add your new gcc, as something like gcc-8 (if you compile GCC 8 from its source code), there. If you want a system wide installation, have some /usr/local/bin/gcc-8 program. If you want a personal installation, have some $HOME/bin/gcc-8 program (both could be absolute symlinks to somewhere else).
I am trying to install opendkim on amazon linux ec2 instance. When compiling from source I get:
configure: error: no strlcpy/strlcat found
so I installed libbsd from source. once that is installed I can go to the man page of strlcat and strlcpy but I can't access those functions. I verified that the shared libraries are installed. The output of the libbsd install stated to use one of the 4 options:
If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,-rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'
I ran
export LD_RUN_PATH=/usr/local/lib
export LD_LIBRARY_PATH=/usr/local/lib/
Additionally my /etc/ld.so.conf contains
include ld.so.conf.d/*.conf
and my /etc/ld.so.conf.d/libbsd.conf contains
/usr/local/lib/libbsd
Lastly checking my libbsd library nm -D /usr/local/lib/libbsd.so contains:
000000000000de30 T strlcat
000000000000ded0 T strlcpy
So my questions how do I either, expose strlcat and strlcpy to the command line? Or how to I do the "use the `-Wl,-rpath -Wl,LIBDIR' linker flag" option, or in general what am i doing wrong in linking to shared libraries? Any help is appreciated. Thanks!
So wasn't ever able to link against the libraries but I was able to resolve the dependencies. The binary rpm from centos installed perfectly :
sudo wget http://dl.fedoraproject.org/pub/epel/7/x86_64/l/libbsd-0.6.0-3.el7.x86_64.rpm
sudo yum localinstall ./libbsd-0.6.0-3.el7.x86_64.rpm
sudo wget http://dl.fedoraproject.org/pub/epel/7/x86_64/l/libbsd-devel-0.6.0-3.el7.x86_64.rpm
sudo yum localinstall ./libbsd-devel-0.6.0-3.el7.x86_64.rpm
The loader gives me this error. I am running Ubuntu 15.04.
When I do: find /usr -type f -name "libGL*"
I get :
/usr/lib/nvidia-352/libGLESv1_CM.so.352.63
/usr/lib/nvidia-352/libGLESv2.so.352.63
/usr/lib/nvidia-352/libGL.so.352.63
/usr/lib/x86_64-linux-gnu/libGLU.so.1.3.1
/usr/lib/x86_64-linux-gnu/libGLEWmx.so.1.10.0
/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0
/usr/lib/x86_64-linux-gnu/libGLEW.so.1.10.0
/usr/lib32/nvidia-352/libGL.la
/usr/lib32/nvidia-352/libGLESv1_CM.so.352.63
/usr/lib32/nvidia-352/libGLESv2.so.352.63
/usr/lib32/nvidia-352/libGL.so.352.63
So, if i know which is the right one, I can include it by -L"thatfile"
How can i tell which is the right one ? Thanks
Depending on whether you want to link a 32 or 64-bit executable you need /usr/lib32/nvidia-352/libGL.so.352.63 or /usr/lib/nvidia-352/libGL.so.352.63. When the linker does not find -lGL, it is looking for libGL.a or libGL.so..
Also, you need to specify only the directory with -L, like -L/usr/lib/nvidia-352.
Finally, even though this way you can link, at runtime the library still won't be found, unless you set LD_LIBRARY_PATH before you run the executable, or if you add -Wl,-rpath,/usr/lib/nvidia-352, too, to the link command (this latter will embed the path into the executable).
/usr/bin/ld: cannot find -lGL
#user85392, the installed GL is the run time files only. For compiling and linking, the development files are required : Libraries and headers → →
$ sudo apt-get update && sudo apt-get install libgl1-mesa-dev libglu1-mesa-dev
When running:
sudo /sbin/ldconfig
the following error appears:
/sbin/ldconfig: /usr/local/lib/ is not a symbolic link
When I run the file command, the below appears:
file /usr/local/lib/
/usr/local/lib/: directory
Inside /usr/local/lib/ there are three libraries that I use. I'll call them here as lib1, lib2 and lib3.
Now, when I do an ldd on my binary it results:
lib1.so => not found
lib2.so => not found
lib3.so => /usr/local/lib/lib3.so (0x00216000)
But all of them are in the same folder as /usr/local/lib/{lib1,lib2,lib3}.so.
Every time I run ldconfig, the same error appears:
/usr/local/lib/ is not a symbolic link
I thought /usr/local/lib should be declared twice in /etc/ld.conf.d/*.conf, but not:
sudo egrep '\/usr\/local' /etc/ld.so.conf.d/*
projectA.conf.old:/usr/local/projectA/lib
local.conf:/usr/local/lib
ld.so.conf only includes /etc/ld.so.conf.d/*.conf, so this *.old isn't processed, and it refers to /usr/local/projectA/lib.
After a time trying I deleted all lib1 and lib2 (at some point I tested it on binary's folder), the same error occurs.
I ran into this issue with the Oracle 11R2 client. Not sure if the Oracle installer did this or someone did it here before I arrived. It was not 64-bit vs 32-bit, all was 64-bit.
The error was that libexpat.so.1 was not a symbolic link.
It turned out that there were two identical files, libexpat.so.1.5.2 and libexpat.so.1. Removing the offending file and making it a symlink to the 1.5.2 version caused the error to go away.
Makes sense that you'd want the well-known name to be a symlink to the current version. If you do this, it's less likely that you'll end up with a stale library.
I simply ran the command below:
export LD_LIBRARY_PATH=/usr/lib/
Now it is working fine.
Solved, at least at the point of the question.
I searched in the web before asking, and there were no conclusive solution, the reason why this error is: lib1.so and lib2.so are not OK, very probably where not compiled for a 64 bit PC, but for a 32 bits machine otherwise lib3.so is a 64 bits lib. At least that is my hypothesis.
VERY unfortunately ldconfig doesn't give a clean error message informing that it could not load the library, it only pumps:
ldconfig: /folder_where_the_wicked_lib_is/ is not a symbolic link
I solved this when I removed the libs not found by ldd over the binary. Now it's easier that I know where lies the problem.
My ld version:
GNU ld version 2.20.51, and I don't know if a most recent version has a better message for its users.
Thanks.
You need to include the path of the libraries inside /etc/ld.so.conf, and rerun ldconfig to upate the list
Other possibility is to include in the env variable LD_LIBRARY_PATH the path to your library, and rerun the executable.
check the symbolic links if they point to a valid library ...
You can add the path directly in /etc/ld.so.conf, without include...
run ldconfig -p to see whether your library is well included in the cache.
I have also faced the same issue,
The solution for it is :
the file for which you are getting the error is probably a duplicated file of the actual file with another version. So just the removal of a particular file on which errors are thrown can resolve the issue.
simple run in shell : sudo apt-get install --reinstall libexpat1
got same problem with libxcb - solved in this way - very fast :)
I experienced a (for me) strange behaviour today: Using QMake with the PkgConfig-options etc. I was able to link the opencv libraries, but then I switched to CMake using PkgConfig. Once I tried to build my software, the linker complained that it was not able to find the library libcvaux, which pkg-config returns asked to deliver the libraries for opencv (pkg-config --libs opencv).
In /usr/lib I found a libcvaux.so.{version}, but no "plain" entry libcvaux.so. So what I did was to create a symlink, and now it works.
Now I wonder why it worked before. Is there something to pass ld an option saying "use the newest version, and you get the version by looking at the numbers behind the so suffix"? Or is it more some kind of bug that the maintainers of the opencv package forgot to add this symlink? Because e.g. libcv or libhighgui have such symbolic links.
Thank you!
From the ldconfig manpage:
ldconfig checks the header and file
names of the libraries it encounters
when determining which versions should
have their links updated.
Maybe an earlier ldconfig run deleted the link.