I'm developing a cross-platform application and I'm having trouble with distributing a Linux binary. In Windows the dll's were - libsndfile-1.dll lua5.1.dll lua51.dll openal32.dll sfml-audio.dll sfml-graphics.dll sfml-network.dll sfml-system.dll sfml-window.dll

This is a very early pre-release, so I don't want to write a package. I'm just interested in having the user download a tarball and run the binary inside. What are the typical ways for users to get these dependencies in Linux, w/o writing a package?

P.S. Also I have Linux 64-bit, and one user reported that the application didn't run on their 32-bit Linux. What could be the issue? I didn't have this issue with Windows (built on a 64-bit system, works on 32-bits).

  • 1
    This should go to SO.
    – Apache
    Commented Jul 17, 2010 at 15:37

4 Answers 4


I'm not sure if this is quite what you're looking for, but typically what's done for Linux programs is that you list the dependencies on the web page where you offer the product for download. In your case, something like

You will need to have the following installed:

(Obviously specify version numbers as well, if your program only works with certain versions) Then a Linux user would check their package manager to make sure they have all those before trying to install your program.

Some programs are distributed the way Ignacio explained, i.e. include all the dependencies you need inside the archive you distribute. That tends to annoy some people a bit because they're stuck with extra copies of the libraries that can't be upgraded, and may even clash with the system versions.

  • Including "all the dependencies you need inside the archive you distribute..." may "clash with the system versions." I know this answer was written 14 years ago, but can anyone give an example of this problem? How significant is this problem? Commented Jan 7 at 17:18
  • It's a big problem if your program gets packaged for a Linux distribution because, if done naively, the files from your archive would overwrite the files from the natively-installed versions of your dependencies. That might lead to incompatible versions of libraries being loaded, forced downgrades, introduction of security flaws, etc. In practice, the package builders will manually strip out the dependencies, but they do not like having to do that. (Granted, the situation is better now because you have the option of containerization, but that's a whole different thing.)
    – David Z
    Commented Jan 8 at 23:42
  • What if you keep your dependencies with your app and don't install them (don't copy them into the directories managed by package managers, like /usr etc.)? Commented Jan 10 at 17:01
  • "if your program gets packaged for a Linux distribution because, if done naively" Oh I think I'm starting to understand. So the clashing would happen if the program gets packaged and added to a package manager. If it isn't installed with a package manager, or the person creating the package is aware of this problem, then things should be okay. (But it might be risky to assume that.) Commented Jan 10 at 19:20

The equivalent in Linux is to include the .so files in a directory within the package, and have a shell script set $LD_LIBRARY_PATH to point to this directory and then run the binary executable.

The problem with 32 vs. 64 is that the compiler generates 64-bit code, and links against 64-bit libraries. You'll need to install a 32-bit toolchain in order to build a 32-bit binary. You can run file against the various binaries in order to confirm this.


You can statically link the program to all libraries but libc and libm. (Heck, you can even link in them).


You can get the dependencies of a binary by using the ldd command

Eg :

ldd program_binary

        libctest.so.1 => /opt/lib/libctest.so.1 (0x00002aaaaaaac000)
        libc.so.6 => /lib64/tls/libc.so.6 (0x0000003aa4e00000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003aa4c00000)

But it is better to share as source because libs could be of different versions having different symbols or from different architecture.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .