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
Related
I am on Debian 8 (Jessie), 64 Bit. I installed libxml2-dev, which now sits in /usr/include/libxml2/libxml.
But when I do (just like libxml docs say)
#include <libxml/parser.h>
I only get when compiling (with gcc)
fatal error: libxml/parser.h: no such file or directory
Notes: On another machine, with an old 64 Bit Suse, where libxml2-dev sits in the exact same path and no other environment vars are set compared to the new Debian, it works perfectly fine. Problem occured while migrating from one to another computer using the exact same makefiles. All other -dev libs that I need just worked (with their documented #include <path>) after the migration (they were all installed with apt-get), only libxml2-dev is not found on compilation.
Do I need to do anything else to make libxml2-dev visible?
if you installed it: sudo apt-get install libxml2-dev libxml2-doc go into /usr/include/libxml2 and copy or move all content from that folder on a level below: cp -R libxml/ ../ After this for me it works.
Try to compile with explicite inclusion where the parser.h file is, i.e. smth like this
g++ -I/usr/include/libxml2/
Following environment variables can also be used for lookup of header files
CPATH
C_INCLUDE_PATH
CPLUS_INCLUDE_PATH
OBJC_INCLUDE_PATH
Find more information here
I came across this same problem on a Centos system. I resolved it by doing the following:
yum install libxml2-devel
cd /usr/include
ln -s libxml2/libxml .
That was it. No change to environment variables or compiler switches.
You should use pkg-config to pass parameters to compiler. Like this
g++ `pkg-config --cflags libxml-2.0` example.c -o example.o
and to linker:
g++ `pkg-config --libs libxml-2.0` example.o -o example
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!
How to add the boost library to a Code::Blocks project in Linux Ubuntu? For example I want to add regex lib.
I've already installed the boost library with:
sudo apt-get install libboost-all-dev
Full example how to will be most valuable.
Just add -lboost_regex to the link options and you should be fine. Other often used dependencies: -lboost_system -lboost_serialization -lboost_thread -lpthread -lboost_filesystem
Two steps to finish:
Include the header files. If you set everything as default, the headers will be installed at
/usr/include/boost
.
2. Select the links you're going to use during compiling. It's default location is
/usr/lib
ATTENTION:
It seems to me that the
-lboost_system
is always needed. So be careful if you need -lboost_filesystem or some libs else.
The problem I faced has been solved here:
Loading shared library in open-mpi/ mpi-run
I know not how, setting LD_LIBRARY_PATH or specifying -x LD_LIBRARY_PATH fixes the problem, when my installation itself specifies the necessary -L arguments. My installation is in ~/mpi/
I have also included my compile-link configs.
$ mpic++ -showme:version
mpic++: Open MPI 1.6.3 (Language: C++)
$ mpic++ -showme
g++ -I/home/vigneshwaren/mpi/include -pthread -L/home/vigneshwaren/mpi/lib
-lmpi_cxx -lmpi -ldl -lm -Wl,--export-dynamic -lrt -lnsl -lutil -lm -ldl
$ mpic++ -showme:libdirs
/home/vigneshwaren/mpi/lib
$ mpic++ -showme:libs
mpi_cxx mpi dl m rt nsl util m dl % Notice mpi_cxx here %
When I compiled with mpic++ <file> and ran with mpirun a.out I got a (shared library) linker error
error while loading shared libraries: libmpi_cxx.so.1:
cannot open shared object file: No such file or directory
The error has been fixed by setting LD_LIBRARY_PATH. The question is how and why? What am i missing? Why is LD_LIBRARY_PATH required when my installation looks just fine.
libdl, libm, librt, libnsl and libutil are all essential system-wide libraries and they come as part of the very basic OS installation. libmpi and libmpi_cxx are part of the Open MPI installation and in your case are located in a non-standard location that must be explicitly included in the linker search path LD_LIBRARY_PATH.
It is possible to modify the configuration of the Open MPI compiler wrappers and make them pass the -rpath option to the linker. -rpath takes a library path and appends its to a list, stored inside the executable file, which tells the runtime link editor (a.k.a. the dynamic linker) where to search for libraries before it consults the LD_LIBRARY_PATH variable. For example, in your case the following option would suffice:
-Wl,-rpath,/home/vigneshwaren/mpi/lib
This would embed the path to the Open MPI libraries inside the executable and it would not matter if that path is part of LD_LIBRARY_PATH at run time or not.
To make the corresponding wrapper add that option to the list of compiler flags, you would have to modify the mpiXX-wrapper-data.txt file (where XX is cc, c++, CC, f90, etc.), located in mpi/share/openmpi/. For example, to make mpicc pass the option, you would have to modify /home/vigneshwaren/mpi/share/openmpi/mpicc-wrapper-data.txt and add the following to the line that starts with linker_flags=:
linker_flags= ... -Wl,-rpath,${prefix}/lib
${prefix} is automatically expanded by the wrapper to the current Open MPI installation path.
In my case, I just simply appends
export LD_LIBRARY_PATH=/PATH_TO_openmpi-version/lib:$LD_LIBRARY_PATH
For example
export LD_LIBRARY_PATH=/usr/local/openmpi-1.8.1/lib:$LD_LIBRARY_PATH
into $HOME/.bashrc file and then source it to active again source $HOME/.bashrc.
I installed mpich 3.2 using the following command on Ubuntu.
sudo apt-get install mpich
When I tried to run the mpi process using mpiexec, I got the same error.
/home/node1/examples/.libs/lt-cpi: error while loading shared libraries: libmpi.so.0: cannot open shared object file: No such file or directory
Configuring LD_LIBRARY_PATH didn't fix my problem.
I did a search for the file 'libmpi.so.0' on my machine but couldn't find it. Took me some time to figure out that 'libmpi.so.0' file is named as 'libmpi.so' on my machine. So I renamed it to 'libmpi.so.0'.
It solved my problem!
If you are having the same problem and you installed the library through apt-get, then do the following.
The file 'libmpi.so' should be in the location '/usr/lib/'. Rename the file to 'libmpi.so.0'
mv /usr/lib/libmpi.so /usr/lib/libmpi.so.0
After that MPI jobs should run without any problem.
If 'libmpi.so' is not found in '/usr/lib', you can get its location using the following command.
whereis libmpi.so
first, run this command
$ sudo apt-get install libcr-dev
if still have this problem then configure LD_LIBRARY_PATH like this:
export LD_LIBRARY_PATH=/usr/local/mpich-3.2.1/lib:$LD_LIBRARY_PATH
then add it to ~/.bashrc before this line:
[ -z "$PS1" ] && return
Simply running
$ ldconfig
appears to me as a better way to solve the problem (taken from a comment on this question). In particular, since it avoids misuse of the LD_LIBRARY_PATH environment variable. See here and here, for why I believe it's misused to solve the problem at hand.
I am attempting to link an application with g++ on this Debian lenny system. ld is complaining it cannot find specified libraries. The specific example here is ImageMagick, but I am having similar problems with a few other libraries too.
I am calling the linker with:
g++ -w (..lots of .o files/include directories/etc..) \
-L/usr/lib -lmagic
ld complains:
/usr/bin/ld: cannot find -lmagic
However, libmagic exists:
$ locate libmagic.so
/usr/lib/libmagic.so.1
/usr/lib/libmagic.so.1.0.0
$ ls -all /usr/lib/libmagic.so.1*
lrwxrwxrwx 1 root root 17 2008-12-01 03:52 /usr/lib/libmagic.so.1 -> libmagic.so.1.0.0
-rwxrwxrwx 1 root root 84664 2008-09-09 00:05 /usr/lib/libmagic.so.1.0.0
$ ldd /usr/lib/libmagic.so.1.0.0
linux-gate.so.1 => (0xb7f85000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7f51000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7df6000)
/lib/ld-linux.so.2 (0xb7f86000)
$ sudo ldconfig -v | grep "libmagic"
libmagic.so.1 -> libmagic.so.1.0.0
How do I diagnose this problem further, and what could be wrong? Am I doing something completely stupid?
The problem is the linker is looking for libmagic.so but you only have libmagic.so.1
A quick hack is to symlink libmagic.so.1 to libmagic.so
As just formulated by grepsedawk, the answer lies in the -l option of g++, calling ld. If you look at the man page of this command, you can either do:
g++ -l:libmagic.so.1 [...]
or: g++ -lmagic [...] , if you have a symlink named libmagic.so in your libs path
It is Debian convention to separate shared libraries into their runtime components (libmagic1: /usr/lib/libmagic.so.1 → libmagic.so.1.0.0) and their development components (libmagic-dev: /usr/lib/libmagic.so → …).
Because the library's soname is libmagic.so.1, that's the string that gets embedded into the executable so that's the file that is loaded when the executable is run.
However, because the library is specified as -lmagic to the linker, it looks for libmagic.so, which is why it is needed for development.
See Diego E. Pettenò: Linkers and names for details on how this all works on Linux.
In short, you should apt-get install libmagic-dev. This will not only give you libmagic.so but also other files necessary for compiling like /usr/include/magic.h.
In Ubuntu, you can install libtool which resolves the libraries automatically.
$ sudo apt-get install libtool
This resolved a problem with ltdl for me, which had been installed as libltdl.so.7 and wasn't found as simply -lltdl in the make.
As mentioned above the linker is looking for libmagic.so, but you only have libmagic.so.1.
To solve this problem just perform an update cache.
ldconfig -v
To verify you can run:
$ ldconfig -p | grep libmagic
Unless I'm badly mistaken libmagic or -lmagic is not the same library as ImageMagick. You state that you want ImageMagick.
ImageMagick comes with a utility to supply all appropriate options to the compiler.
Ex:
g++ program.cpp `Magick++-config --cppflags --cxxflags --ldflags --libs` -o "prog"
Installing libgl1-mesa-dev from the Ubuntu repo resolved this problem for me.
I tried all solutions mentioned above but none of them solved my issue but finally I solved it with the following command.
sudo apt-get install libgmp3-dev
This will do the magic.
Another way to solve this problem is to install the -devel package.
If the compiler is looking for libabc.so while you have libabc.so.1, you need to install the -devel package like libabc-devel as libabc.so.1 is a runtime lib but libabc.so is a development lib.