I wrote a mini client-server game that works fine on my computers (running linux), since I installed SFML (and GCC 4.8) on both the Client and Server. Now I want to deploy the server application to another Linux that does not have SFML.
First I tried to dynamic link the SFML libraries used (network and system):
g++ server.cpp -o ServerLinux -std=c++11 -Os -lsfml-network -lsfml-system
But when I run the Server application it says it could not find sfml-network.so.2 and sfml-system.so.2 even though those 2 files are on the same folder of the binary.
I then static linked both libraries:
g++ -DSFML_STATIC server.cpp -o ServerLinux -std=c++11 -Os -lsfml-network-s -lsfml-system-s
And then when I run it says it could not find GLIBC_2.15 and GLIBC_2.17
Finally on my last try I static linked both libstc++ and libgcc:
g++ -DSFML_STATIC server.cpp -o ServerLinux -std=c++11 -Os -lsfml-network-s -lsfml-system-s -static-libstdc++ -static-libgcc
But I still get the same error (could not find GLIBC_2.15 and GLIBC_2.17).
Reading similar problems it seems that one should never static link glibc. But I don't know how to proceed, how can I deploy my mini game-server to a Linux box that does not have SFML?
Linux systems search for shared libraries by utilizing the LD_LIBRARY_PATH environment variable and they don't automatically look for binary files next to the application, as it is the case on Windows.
An very often used method of deploying with shared libraries, is to include them in an sub-directory or similar and instead of launching the application directly run a shell script that would add the directory with the libraries temporarily to ?LD_LIBRARY_PTH` and then start the application.
The other issue you're having is related to dependencies.
For shared libraries you'd not only have to provide the shared SFML libraries, but also provide the shared libraries of the dependencies, unless you can 100% guarantee that the target system will have the equal library version.
If you just build static libraries of SFML, they'll still point to shared runtime libraries and alike, thus if you don't provide the matching version with the application, it will simply fail to start, since it can't find the library. If you link statically against the runtime libraries you wouldn't need to provide shared libraries for your application, but since the SFML libraries were still link dynamically against the runtime libraries, they request the shared libraries anyways.
So if you don't want to any shared library files any more, you'll need to link SFML statically against the runtime library (uncheck BUILD_SHARED_LIBS and check SFML_USE_STATIC_STD_LIBS).
Keep in mind that when linking statically, you'll need to link statically against all dependencies - -static might be useful.