Moving programs compiled on a machine to another machine & avoid library dependencies problems

Question

When I compile a program with .dll dependencies on Windows, it is enough to copy those ddls with the desired program to another pc and put the DLLs inside the program directory.

Now here is my problem: I've compiled a program with Ubuntu using clang and clang++, when I transferred my compiled program to my server (CentOS), the program doesn't load because of missing libraries. I thought to transfer my libraries from my pc to the server but I don't know if it is possible.

I can't install programs in that server because I don't have root password, so is there a way to solve this problem?

Solution

Arbitrarily copying .so files to system-wide directories is not a good practice as it will copy shared libraries to the destination system without the Package System Control awareness, thus it can cause conflicts with installed software and may lack other dependencies you cannot easily map manually.

Your mileage may vary, but there are three different approaches you can look for:

The first is trying to install the necessary software packages that contain the compatible versions of the libraries in the destination distro. This requires root, though, that you indicated as not being an option. In any case, if this turns to be an option at some point, here are some hints to help in this approach: ldd you_executable_file shows the library dependencies of a specific program. You can look for packages in the distro that provides such libraries (in Fedora, for example, you can use yum provides path_to_required_file to tell you which packages are needed to be installed.

The second is trying to produce a distribution agnostic executable. For such purpose you should use static libraries instead when compiling your software. Typically you can find both shared (.so) and static (.a) versions of most of the libraries in Linux. You should use the static versions and link them as if they were object files (.o). The down side is that the generated binary will be much bigger than when using shared libraries because it will carry all the library code within itself. Additionally, it will not be sensitive to bug fixes in those libraries that are later installed in the system (this will require recompiling your program with the new fixed version).

The third option is indeed copying the libraries to the new system (even not being root) to a directory under your home dir and use the LD_LIBRARY_PATH and/or LD_PRELOAD environment variables to force the dynamic linker to use your copies of the libraries. Notice that you may need to copy many libraries (which you will discover using the ldd command I mentioned above.). LD_LIBRARY_PATH tells the dynamic linker to look at additional paths to find missing libraries. LD_PRELOAD forces the dynamic linker to pre-load a specific version of a library overriding the system-wide version.

Comments

[Leon Kramer]

You can copy the library files too and alter the environment variables for the script so they are loaded with the script