In other words, can an application that runs on one distro be simply copied and run on another distro?


It depends on how the application is build. One problem can be system paths that might differ from distribution to distribution. Another problem are shared libraries which might not be installed on the target system, or worse might be installed in incompatible versions.

One solution to the libraries problem is to either build statically linked binaries or (like it's common on OS X) to just ship all required libs with the application and if necessary set LD_LIBRARY_PATH accordingly (though this is a bad idea for so many reasons).

An easy way to check if your program will run is to list all the linked libraries using ldd and see if they exist on the target system.

Example using apache httpd:

[lukas@web1 /]$ ldd /usr/sbin/httpd
        libm.so.6 => /lib64/libm.so.6 (0x00002b1ec3aaf000)
        libpcre.so.0 => /lib64/libpcre.so.0 (0x00002b1ec3d32000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b1ec3f4e000)
        libaprutil-1.so.0 => /usr/lib64/libaprutil-1.so.0 (0x00002b1ec4167000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002b1ec4384000)
        libldap-2.3.so.0 => /usr/lib64/libldap-2.3.so.0 (0x00002b1ec45bc000)
        liblber-2.3.so.0 => /usr/lib64/liblber-2.3.so.0 (0x00002b1ec47f7000)
        libdb-4.3.so => /lib64/libdb-4.3.so (0x00002b1ec4a05000)
        libexpat.so.0 => /lib64/libexpat.so.0 (0x00002b1ec4cfa000)
        libapr-1.so.0 => /usr/lib64/libapr-1.so.0 (0x00002b1ec4f1d000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b1ec5144000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002b1ec535f000)
        libc.so.6 => /lib64/libc.so.6 (0x00002b1ec5564000)
        libsepol.so.1 => /lib64/libsepol.so.1 (0x00002b1ec58bb000)
        /lib64/ld-linux-x86-64.so.2 (0x00002b1ec3892000)
        libuuid.so.1 => /lib64/libuuid.so.1 (0x00002b1ec5b01000)
        libpq.so.4 => /usr/lib64/libpq.so.4 (0x00002b1ec5d06000)
        libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x00002b1ec5f28000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00002b1ec6183000)
        libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00002b1ec6399000)
        libssl.so.6 => /lib64/libssl.so.6 (0x00002b1ec65b2000)
        libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002b1ec67fc000)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002b1ec6b4e000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00002b1ec6de3000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002b1ec6ffc000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002b1ec722a000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002b1ec742c000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00002b1ec7652000)
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002b1ec7866000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002b1ec7a6e000)

If all the linked libraries exist in a compatible version on the target system, it's likely your application will be able to start. From there on it's mostly paths that have to be adjusted.

  • Good answer! Also important in this answer is the word "likely". Even if ldd is happy (all dependencies fulfilled) your application may not work as expected because something in one of the dependency libs is not ABI compatible. for more reading here is an example: access.redhat.com/articles/rhel-abi-compatibility – Trevor Boyd Smith Aug 21 '15 at 14:27

It depends on the glibc version amongst other things. Its generally not a good idea to since file system structures might vary.


It depends on the complexity of the application, as well as on the dependencies and libraries it links to.

If the application is stand-alone, simple, has no external dependencies and is compiled on the same CPU architecture - it should work.

In more complicated scenarios, it's hard to tell. For sure, to have any chance, the application need to be for the same CPU arch, same glibc version, and the 2 distros need to be with a common base - i.e. it's easier to run debian app on ubuntu, etc.

If you want to build such an application, and be able to run it on any distro - then you need to compile it with statically linked libraries, and to nor relay on the OS filesystem layout and to assume that some files will be located at specific locations.

Id it's not you who builds the application - then better use the specific distro's pre-build packages, or compile from source.

All above is true for "compiled" application. If it's some scripting language application - ruby, php, perl, python, etc., most probably (if the interpreter version is the same) you can just copy it - again, if the app does not assume some files are at specific locations. But this can be solved, as you can modify the script to suit the move.


If the processor architecture is the same I can't see why this wouldn't work.

  • 2
    It really depends on how the application has been built. In the most general case, even on the same processor architecture, it won't work – Dominik Mar 9 '10 at 15:22
  • ex: application built on MS Windows won't work on Apple OSX even though both may have the same x86_64 architecture. – Trevor Boyd Smith Aug 21 '15 at 14:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.