2

I have an application configured using CMake and build with GCC. I'm building on one Linux system and try to run it on another. Unfortunately both systems supply different versions of the same lib. For example GLEW, so whenever I try to run executable on the second system I'm getting this:

./app
./app: error while loading shared libraries: libGLEW.so.2.0: cannot open shared object file: No such file or directory

Here are relevant outputs of app reference and what I have in my system.

ldd ./app | awk '{print $1}' | grep GLEW
libGLEW.so.2.0
ldconfig -p | grep GLEW
        libGLEW.so.2.2 (libc6,x86-64) => /usr/lib/libGLEW.so.2.2
        libGLEW.so.2.2 (ELF) => /usr/lib32/libGLEW.so.2.2
        libGLEW.so.2.1 (libc6,x86-64) => /usr/lib/libGLEW.so.2.1
        libGLEW.so (libc6,x86-64) => /usr/lib/libGLEW.so
        libGLEW.so (ELF) => /usr/lib32/libGLEW.so

I actually would like to configure CMake or whatever to reference the "least common denominator" filename, so instead of libGLEW.so.2.0 it should ref to libGLEW.so

[EDIT] Some additional outputs from the builder OS:

cat CMakeCache.txt  | grep GLEW
...
GLEW_LIBRARIES:FILEPATH=/usr/lib/x86_64-linux-gnu/libGLEW.so
...

ls -al /usr/lib/x86_64-linux-gnu/libGLEW.so
lrwxrwxrwx 1 root root 16 Jan 12  2019 /usr/lib/x86_64-linux-gnu/libGLEW.so -> libGLEW.so.2.1.0

So basically CMake gets it right, but then the GCC linker follows the link and actually places a version specific filename as a reference.

lhog
  • 105
  • 1
  • 8
  • The glew library itself needs to have an appropriate soname, if it doesn't have one that may indicate it doesn't support binary compatibility between versions – Alan Birtles Oct 19 '20 at 22:30

3 Answers3

0

In this case I would instruct cmake to link against the shared library generic name, which should be libGLEW.so or similar and be a symbolic link to a specific version of the library. Check in /usr/lib. If it does not exist on the build machine or the execution machine, you may need to create it. However, note that there may not be binary compatibility between two versions of libGLEW, as @AlanBirtles pointed out.

Anonymous1847
  • 2,568
  • 10
  • 16
  • My CMake seems to be finding the right shared lib: //Path to a library. GLEW_LIBRARIES:FILEPATH=/usr/lib/x86_64-linux-gnu/libGLEW.so ls -al /usr/lib/x86_64-linux-gnu/libGLEW.so lrwxrwxrwx 1 root root 16 Jan 12 2019 /usr/lib/x86_64-linux-gnu/libGLEW.so -> libGLEW.so.2.1.0 but then ldd follows the symlink and I get the executable with the "wrong" lib name inside – lhog Oct 19 '20 at 23:44
  • "In this case I would instruct cmake to link against the shared library generic name". Wish I knew how. – lhog Oct 19 '20 at 23:50
0

As of cmake 3.15 there is now a cmake module to find glew and handle this better.

Here is a link to the module: https://cmake.org/cmake/help/latest/module/FindGLEW.html?highlight=glew

You should be able to figure it out from there.

  • Did my suggestion answer your question? If not I can try and help out more. –  Oct 25 '20 at 05:23
0

For now I have converged on using patchelf. The solution is based on How can I change the filename of a shared library after building a program that depends on it?

  1. Install patchelf on your linux build host. In my case it's ubuntu, so apt-get install -y patchelf
  2. Check the app dependencies: patchelf --print-needed ./app, which in my case yields:
libSDL2-2.0.so.0
libpthread.so.0
libGL.so.1
libGLU.so.1
libGLEW.so.2.1
libfontconfig.so.1
libfreetype.so.6
libXcursor.so.1
libX11.so.6
libdl.so.2
libIL.so.1
libminizip.so.1
libz.so.1
libunwind.so.8
libvorbisfile.so.3
libopenal.so.1
libcurl.so.4
libstdc++.so.6
libm.so.6
libgcc_s.so.1
libc.so.6
  1. Next replace the links to all missing libraries. In my case it was only libGLEW.so.2.1, so patchelf --replace-needed libGLEW.so.2.1 libGLEW.so ./app Now re-verify of the list of linked libs: patchelf --print-needed ./app
libSDL2-2.0.so.0
libpthread.so.0
libGL.so.1
libGLU.so.1
libGLEW.so
libfontconfig.so.1
libfreetype.so.6
libXcursor.so.1
libX11.so.6
libdl.so.2
libIL.so.1
libminizip.so.1
libz.so.1
libunwind.so.8
libvorbisfile.so.3
libopenal.so.1
libcurl.so.4
libstdc++.so.6
libm.so.6
libgcc_s.so.1
libc.so.6

Note libGLEW.so.2.1 got changed into libGLEW.so

P.S. I don't consider this a proper solution, so any suggestions how to handle linking properly in the first place are more than welcome.

lhog
  • 105
  • 1
  • 8