1
General / SFML on Linux - Shared Library versions
« on: April 19, 2014, 08:22:14 pm »
Hello,
I'm trying to get the example program (http://www.sfml-dev.org/tutorials/2.1/start-linux.php) to compile and run on my linux box. I'm using ubuntu 13.10 btw.
I downloaded the precompiled shared libraries from here: http://www.sfml-dev.org/download/sfml/2.1/
I followed the tutorial, when I try to link my object file I get this error:
He also suggested to not distribute the shared libs along with the program, but seeing as SFML2.1 hasn't yet been incorporated in the ubuntu packages I have no other choice.
Imagine this situation:
I want to create a program with SFML and distribute it, to be used on multiple ubuntu versions or even linux distros.
As stated above I'll have to distribute the shared SFML libs along with the program, but what about the shared glew, jpeg, xlib, ... libs ? If I were to recompile SFML on my system, won't that 'lock' the binary with the versions of those libs I had on my pc at that time ? for example, if I have version 1.8 of some library, and someone tries to run my program but only has version 1.5, will it still work ? And if I compile for version 1.5, will it work for version 1.8 ?
I hope my questions are clear.
I'm trying to get the example program (http://www.sfml-dev.org/tutorials/2.1/start-linux.php) to compile and run on my linux box. I'm using ubuntu 13.10 btw.
I downloaded the precompiled shared libraries from here: http://www.sfml-dev.org/download/sfml/2.1/
I followed the tutorial, when I try to link my object file I get this error:
/usr/bin/ld: warning: libGLEW.so.1.5, needed by ./lib/libsfml-graphics.so, not found (try using -rpath or -rpath-link)
./lib/libsfml-graphics.so: undefined reference to `__glewUniform1fARB'
./lib/libsfml-graphics.so: undefined reference to `__GLEW_ARB_shader_objects'
./lib/libsfml-graphics.so: undefined reference to `__glewGetObjectParameterivARB
and a whole bunch more undefined glew references
I know I have the most recent version of glew, so it's just a version mismatch. After looking around on this forum I saw Laurent told someone to just compile SFML on their own pc to get rid of all version mismatches../lib/libsfml-graphics.so: undefined reference to `__glewUniform1fARB'
./lib/libsfml-graphics.so: undefined reference to `__GLEW_ARB_shader_objects'
./lib/libsfml-graphics.so: undefined reference to `__glewGetObjectParameterivARB
and a whole bunch more undefined glew references
He also suggested to not distribute the shared libs along with the program, but seeing as SFML2.1 hasn't yet been incorporated in the ubuntu packages I have no other choice.
Imagine this situation:
I want to create a program with SFML and distribute it, to be used on multiple ubuntu versions or even linux distros.
As stated above I'll have to distribute the shared SFML libs along with the program, but what about the shared glew, jpeg, xlib, ... libs ? If I were to recompile SFML on my system, won't that 'lock' the binary with the versions of those libs I had on my pc at that time ? for example, if I have version 1.8 of some library, and someone tries to run my program but only has version 1.5, will it still work ? And if I compile for version 1.5, will it work for version 1.8 ?
I hope my questions are clear.