I built GLEW (using make install) to use in a small test program I am writing (source can be found here if you need it). I ran locate libGLEW.so just to check if the GLEW libraries were properly installed, and got the following output:
/usr/lib64/libGLEW.so
/usr/lib64/libGLEW.so.2.0
/usr/lib64/libGLEW.so.2.0.0
This was completely normal. I then compiled it using the command:
g++ main.cpp -o main -lglfw -lGLEW -lGL -lX11 -lpthread -lXi -g
This also threw up no errors. However, when I tried to execute the program:
./main: error while loading shared libraries: libGLEW.so.2.0: cannot open shared object file: No such file or directory
Just for a sanity check, I ran ldd main | grep "GLEW", and sure enough:
libGLEW.so.2.0 => not found
I initially thought that this could be a problem with the linker not searching the directory containing the libraries. So I ran the command ld --verbose | grep "/usr/lib64" and there was a SEARCH_DIR containing the required directory:
... SEARCH_DIR("=/usr/lib64"); ...
This was especially confusing. I tried compiling with the -L/usr/lib64 option, but the same error message still persisted. I checked that the symlinks to the library were correct and they were:
lrwxrwxrwx 1 root root 16 Jul 15 10:22 libGLEW.so -> libGLEW.so.2.0.0
lrwxrwxrwx 1 root root 16 Jul 15 10:38 libGLEW.so.2.0 -> libGLEW.so.2.0.0
-rw-r--r-- 1 root root 707K Jul 15 10:22 libGLEW.so.2.0.0
I am not sure what exactly is causing the issue but I'm starting to believe that I didn't install the libraries correctly. I feel like the answer is right in front of my eyes but I can't find it.
Thanks in advance for any help.
Debian and Ubuntu do not install system libraries into /usr/lib64, and the installation instructions you used are wrong for those systems. (It is not a good idea to install libraries bypassing the packaging system into /usr anyway.) /usr/local/lib is searched by default (unlike other systems), so you could move the libraries to that directory.
Compile with -Wl,-rpath=/usr/lib64
Related
I'm trying to test out the Kotlin Game engine called Korge. I downloaded the default "Hello world!" template directly from their website.
After downloading, I created a new project from existing files with IDEA and tried to run gradle's script called "runNativeDebug".
I'm currently running Manjaro
uname -a
Linux lifeordeath-pc 4.19.45-1-MANJARO #1 SMP PREEMPT Wed May 22 17:16:41 UTC 2019 x86_64 GNU/Linux
I've tried downloading openal, lib32-openal and freeglut from the AUR repositories. Libraries do get installed, which can be seen from the following
ls /usr/lib | grep -E "glu|openal"
libglui.a
libglui.so.2
libglut.so
libglut.so.3
libglut.so.3.10.0
libopenal.a
libopenal.so
libopenal.so.1
libopenal.so.1.19.1
This is the header file location
ls /usr/include/GL | grep gl
freeglut_ext.h
freeglut.h
freeglut_std.h
glcorearb.h
glew.h
glext.h
gl.h
gl_mangle.h
glu.h
glui.h
glu_mangle.h
glut.h
glxew.h
glxext.h
glx.h
glxint.h
glx_mangle.h
glxmd.h
glxproto.h
glxtokens.h
wglew.h
Download the Template and just run it.
I expected code to just run, but upon clicking the run button, I'm greeted by the following error:
/home/lifeordeath/.konan/dependencies/clang-llvm-6.0.1-linux-x86-64/bin/ld.lld: error: unable to find library -lGL
/home/lifeordeath/.konan/dependencies/clang-llvm-6.0.1-linux-x86-64/bin/ld.lld: error: unable to find library -lGLU
/home/lifeordeath/.konan/dependencies/clang-llvm-6.0.1-linux-x86-6 /bin/ld.lld: error: unable to find library -lglut
/home/lifeordeath/.konan/dependencies/clang-llvm-6.0.1-linux-x86-64/bin/ld.lld: error: unable to find library -lopenal
error: /home/lifeordeath/.konan/dependencies/clang-llvm-6.0.1-linux-x86-64/bin/ld.lld invocation reported errors
Furthermore, JS build of the template works flawlessly.
In the case someone else is facing this issue on Debian-based distros like Ubuntu:
The solution is here: https://korlibs.soywiz.com/korge/targets/desktop/
sudo apt-get -y install freeglut3-dev libopenal-dev
I am trying to compile a program that requires SFML 2.41+. Ubuntu 16.04's repos don't have a new enough version so I installed SFML 2.4.2 by following the (somewhat sparse) instructions on this page. Specifically I dowloaded the Linux version from this page, extracted it, dug down until I found the lib, share, and include folders and copied those folders over the folders of the same name in /usr/local/.
When running the included Makefile I get the following errors:
/usr/bin/ld: cannot find -lsfml-system
/usr/bin/ld: cannot find -lsfml-window
/usr/bin/ld: cannot find -lsfml-graphics
Focusing on sfml-system for the moment, if I run ld -lsfml-system --verbose | grep /usr/local/lib I get the following:
attempt to open //usr/local/lib/x86_64-linux-gnu/libsfml-system.so failed
attempt to open //usr/local/lib/x86_64-linux-gnu/libsfml-system.a failed
attempt to open //usr/local/lib/libsfml-system.so failed
attempt to open //usr/local/lib/libsfml-system.a failed
if I run sudo ls -l /usr/local/lib | grep libsfml-system.so I get the following:
lrwxrwxrwx 1 root root 21 Oct 16 01:38 libsfml-system.so -> libsfml-system.so.2.4
lrwxrwxrwx 1 root root 23 Oct 16 01:38 libsfml-system.so.2.4 -> libsfml-system.so.2.4.2
-rw-r--r-- 1 root root 72080 Feb 10 2017 libsfml-system.so.2.4.2
So I appear to have a symlink to a .so file in the path ld is looking in.
Why can't it load the library?
(I was initially concerned about the double slashes, but this question suggests those are okay.)
what i've tried so far
I've now tried running sudo ldconfig and sudo ldconfig /usr/local/lib/. Neither of those have changed the behaviour of ld -lsfml-system
Specifcally when I run sudo ldconfig --verbose 2> /dev/null | grep sfml I get
libsfml-window.so.2.4 -> libsfml-window.so.2.4.2
libsfml-graphics.so.2.4 -> libsfml-graphics.so.2.4.2
libsfml-audio-d.so.2.4 -> libsfml-audio-d.so.2.4.2
libsfml-graphics-d.so.2.4 -> libsfml-graphics-d.so.2.4.2
libsfml-audio.so.2.4 -> libsfml-audio.so.2.4.2
libsfml-window-d.so.2.4 -> libsfml-window-d.so.2.4.2
libsfml-system.so.2.4 -> libsfml-system.so.2.4.2
libsfml-system-d.so.2.4 -> libsfml-system-d.so.2.4.2
libsfml-network-d.so.2.4 -> libsfml-network-d.so.2.4.2
libsfml-network.so.2.4 -> libsfml-network.so.2.4.2
libsfml-network.so.2.3 -> libsfml-network.so.2.3.2
libsfml-graphics.so.2.3 -> libsfml-graphics.so.2.3.2
libsfml-system.so.2.3 -> libsfml-system.so.2.3.2
libsfml-window.so.2.3 -> libsfml-window.so.2.3.2
(On stderr I just get messages that appear to be merely informational,for example:
/sbin/ldconfig.real: Path `/usr/local/lib' given more than once
and
/sbin/ldconfig.real: /lib/i386-linux-gnu/ld-2.23.so is the dynamic linker, ignoring
so I figured they weren't important.)
Since /etc/ld.so.cache was mentioned, I made a copy of it with cp /etc/ld.so.cache /etc/ld.so.cache.bak and re-ran sudo ldconfig. A new cache file was generated but it wasn't any different, that is diff /etc/ld.so.cache /etc/ld.so.cache.bak doesn't print anything.
The problem turned out to be that the permissions on my /usr/local/lib/ got changed when I copied the files over them. Specifically the execute bits seem to have been unset. After setting those again, I can now link those libraries properly!
The standard Linux libraries are cached in /etc/ld.so.cache. If you add libraries to the standard path, you need to also run (as root) ldconfig.
I'm failing to link against OpenGL in my C++/Qt5 projects. I link using the following command:
g++ -m64 -Wl,[...] -o [...] [...].o \
-L/usr/X11R6/lib64 -L[...]/qt-5.0.0/5.0.0/gcc_64/lib \
-lQt5Widgets -lQt5Network -lQt5Gui -lQt5Core -lGL -lpthread
I hope the [...] aren't hiding something important. If you think they are, please let me know.
I get the following error:
/usr/bin/ld: cannot find -lGL
I'm on an Lubuntu 12.10 system and using Qt5 from http://qt-project.org/downloads. Since the system is newly installed, the first thing I did was installing Ubuntu's nvidia-current package and I rebooted. Among others, the following libraries have been installed on my system:
$ ll /usr/lib/nvidia-current/
[...]
lrwxrwxrwx 1 root root 10 Oct 6 04:58 libGL.so -> libGL.so.1
lrwxrwxrwx 1 root root 15 Oct 6 04:58 libGL.so.1 -> libGL.so.304.43
-rw-r--r-- 1 root root 1076560 Oct 6 04:58 libGL.so.304.43
[...]
I googled on how to add this path to the default library search path, as I guessed that g++ doesn't look in the subfolder nvidia-current but only in /usr/lib. So I added the path to ld.conf.d in Ubuntu. I updated ldconfig and checked with the following command:
$ ldconfig -p | grep libGL.so
libGL.so.1 (libc6,x86-64) => /usr/lib/nvidia-current/libGL.so.1
libGL.so.1 (libc6) => /usr/lib32/nvidia-current/libGL.so.1
libGL.so (libc6,x86-64) => /usr/lib/nvidia-current/libGL.so
libGL.so (libc6) => /usr/lib32/nvidia-current/libGL.so
So everything looks just fine!
Still (even after rebooting), the error from above appears. Am I missing something?
Edit:
After adding -L/usr/lib/nvidia-current/, everything works fine. But it seems that this is not the correct way to link against a library in a default path.
It's common for distributions to install graphics drivers' libGL not into the system library path, but some additional directory in /usr/lib to allow for installing different variants of libGL.so on the same system. Then symlinks to the active libGL.so are created by some centralized configuration system, for example alternatives as used by Ubuntu and Debian. It may very well be, that this configuration step failed.
/usr/lib/nvidia-current is not a standard library path and hence the library is not found; this also should mean, that OpenGL programs should not work. Maybe the Ubuntu folks do something with the LD_LIBRARY_PATH environment variable to circumvent this.
Personally I suggest that you add symlinks, as you should always have libGL.so in the defaul library path, preferrably /usr/lib or on 32/64 bit multilib systems in /usr/lib64 and /usr/lib32
/usr/lib/libGL.so.1 => /usr/lib/nvidia-current/libGL.so.1
/usr/lib32/libGL.so.1 => /usr/lib32/nvidia-current/libGL.so.1
/usr/lib/libGL.so => /usr/lib/nvidia-current/libGL.so
/usr/lib32/libGL.so => /usr/lib32/nvidia-current/libGL.so
You can also do this using the alternatives system, adding a new alternative.
I am trying to link Mathlink libraries in mathematica. I am using a x86_64-suse-linux OS, but when I check $SystemID in Mathematica, it tells me I am using 'Linux' instead of 'Linux-x86-64'.
This is a problem because if I try to link the library as
g++ cpp2mma.cpp -L/usr/local/Wolfram/Mathematica/8.0/SystemFiles/Links/MathLink/DeveloperKit/Linux/CompilerAdditions/ -lML32i3 -lpthread -lstdc++ -lm -lrt
(the 32 bit version - and the only library in Linux/)
I get the following error:
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: skipping incompatible
/usr/local/Wolfram/Mathematica/8.0/SystemFiles/Links/MathLink/DeveloperKit/Linux/CompilerAdditions//libML32i3.so when searching for -lML32i3
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: skipping incompatible
/usr/local/Wolfram/Mathematica/8.0/SystemFiles/Links/MathLink/DeveloperKit/Linux/CompilerAdditions//libML32i3.a when searching for -lML32i3
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: cannot find -lML32i3
collect2: ld returned 1 exit status
however, if I try to link it as
g++ cpp2mma.cpp -L/usr/local/Wolfram/Mathematica/8.0/SystemFiles/Links/MathLink/DeveloperKit/Linux-x86-64/CompilerAdditions/ -lML64i3 -lpthread -lstdc++ -lm -lrt
it compiles just fine, but if I try to run it I get the following error:
./a.out: error while loading shared libraries: libML64i3.so: cannot open shared object file: No such file or directory
This file obviously exists as running 'locate libML64i3.so' yields:
/usr/local/Wolfram/Mathematica/8.0/SystemFiles/Libraries/Linux-x86-64/libML64i3.so
/usr/local/Wolfram/Mathematica/8.0/SystemFiles/Links/MathLink/DeveloperKit/Linux-x86-64/CompilerAdditions/libML64i3.so
Am I correct in assuming that the problem lies in the fact that Mathematica thinks that I am not running a 32 bit system? If so, what do I do?
The problem is not in Mathematica. The kernel is never running -- from the perspective of e system you are compiling and launching an ELF executable. libML64i3 will start a kernel for you, but its not getting loaded here.
There are several ways to get the linker to find libML64i3.so at runtime
Export the directory containing libML64i3.so through LD_LIBRARY_PATH (generally not a good idea)
use an entry in /etc/ld.so.conf.d or /etc/ld.so.conf to indicate that /usr/local/Wolfram/Mathematica/8.0/SystemFiles/Links/MathLink/DeveloperKit/Linux-x86-64/CompilerAdditions should be part of the library search path -- look at ldconfig(8).
Symlink libML64i3.so somewhere already in the library search path
Link to a static version of libML, as described in this StackOverflow post.
To deal with the compile-time linker errors, you could compile your application 32-bit (by passing -m32 to g++). If you did this, you would get a runtime message griping about not being able to find the 32-bit version of libML, which would require the same solution as above.
I'm not sure why $SystemID is returning a value indicating you are running the 32-bit kernel. That probably has something to do with how you are starting Mathematica. On CentOS 5-7-x86_64, I have
host 11% ls -l $(which math)
lrwxrwxrwx 1 root root 51 Nov 8 16:27 /usr/local/bin/math -> \
/usr/local/Wolfram/Mathematica/8.0/Executables/math
host 12% math
Mathematica 8.0 for Linux x86 (64-bit)
Copyright 1988-2011 Wolfram Research, Inc.
In[1]:= $SystemID
Out[1]= Linux-x86-64
I met the share library not found on the head node of a cluster with torch. I have built the library as well as specify the correct path of the library while compiling my own program "absurdity" by g++. So it looks strange to me. Any idea? Thanks and regards!
[tim#user1 release]$ make
...
...
g++ -pipe -W -Wall -fopenmp -ggdb3 -O2 -I/home/tim/program_files/ICMCluster/ann_1.1.1/include -I/home/tim/program_files/ICMCluster/libsvm-2.89 -I/home/tim/program_files/ICMCluster/svm_light -o absurdity xxxxxx.o -L/home/tim/program_files/ICMCluster/ann_1.1.1/release/lib -L/home/tim/program_files/ICMCluster/libsvm-2.89/release/lib -L/home/tim/program_files/ICMCluster/svm_light/release/lib -lm -ljpeg -lpng -lz -lANN -lpthread -lsvm -lsvmlight
[tim#user1 release]$ ./absurdity
./absurdity: error while loading shared libraries: libsvmlight.so: cannot open shared object file: No such file or directory
[tim#user1 release]$ ls /home/tim/program_files/ICMCluster/svm_light/release/lib/libsvmlight.so -l
-rwxr-xr-x 1 tim Brown 121407 Jan 31 12:14 /home/tim/program_files/ICMCluster/svm_light/release/lib/libsvmlight.so
[tim#user1 release]$ LD_LIBRARY_PATH= /home/tim/program_files/ICMCluster/svm_light/release/lib:$LD_LIBRARY_PAT
[tim#user1 release]$ export LD_LIBRARY_PATH
[tim#user1 release]$ ./absurdity
./absurdity: error while loading shared libraries: libsvmlight.so: cannot open shared object file: No such file or directory
[tim#user1 release]$ ls /home/tim/program_files/ICMCluster/svm_light/release/lib
libsvmlight.a libsvmlight.so
Copied from my answer here: https://stackoverflow.com/a/9368199/485088
Run ldconfig as root to update the cache - if that still doesn't help, you need to add the path to the file ld.so.conf (just type it in on its own line) or better yet, add the entry to a new file (easier to delete) in directory ld.so.conf.d.
Your LD_LIBRARY_PATH doesn't include the path to libsvmlight.so.
$ export LD_LIBRARY_PATH=/home/tim/program_files/ICMCluster/svm_light/release/lib:$LD_LIBRARY_PATH
sudo ldconfig
ldconfig creates the necessary links and cache to the most recent shared libraries found in the directories specified on the command line, in the file /etc/ld.so.conf, and in the trusted directories (/lib and /usr/lib).
Generally package manager takes care of this while installing the new library, but not always (specially when you install library with cmake).
And if the output of this is empty
$ echo $LD_LIBRARY_PATH
Please set the default path
$ LD_LIBRARY_PATH=/usr/local/lib
When working on a supercomputer, I received this error when I ran:
module load python/3.4.0
screen
python
To resolve the error, I simply needed to reload the module in the screen terminal:
module load python/3.4.0
python