ldd tells me my app is "not a dynamic executable"

Question

I have a 32-bit application (called uclsyn) I received from an astronomy professor. I managed to get it running on CentOS a year ago, but now when I am setting up a new CentOS VM, it won't run and I can't work out why. It keeps coming back with "Killed".

This is the exchange on the command line:

$ ./uclsyn_linux
Killed

$ ldd ./uclsyn_linux
not a dynamic executable

$ file ./uclsyn_linux
uclsyn_linux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

On the machine which is does run on, "ldd ./uclsyn_linux" returns a whole list of dependencies. I've found the packages which provide these shared libraries, and they all appear to be installed.

Packages required

• libSM-1.1.0-7.1.el6.i686
• libX11-1.3-2.el6.i686
• libgcc-4.4.6-3.el6.i386
• glibc-2.12-1.47.el6_2.9.i686
• libuuid-2.17.2-12.4.el6.i686
• libXau-1.0.5-1.el6.i686
• There are also a heap of libraries local to the application which I have checked and are already installed.

My environment

CentOS running under VirtualBox

uname -a: Linux localhost.localdomain 2.6.32-358.el6.i686 #1 SMP Thu Feb 21 12:50:49 UTC 2013 i686 i686 i386 GNU/Linux

Answer 1

I just had the problem with a 32-bit binary, solution was:

apt-get install gcc-multilib

$ uname -a
Linux bla 2.6.32-028stab094.3 #1 SMP Thu Sep 22 12:47:37 MSD 2011 x86_64 GNU/Linux

Answer 2

The error here was due to not having enough RAM on the VirtualMachine. Running strace ./programname indicated that the program was being killed just as it started running, before loading any of the libraries. Increasing the amount of RAM available ensured that the program could work.

Useful responses

There were some useful responses from others namely @slm who provided useful commands to check that each of the libraries existed, and @lgeorget who suggesting trying the strace command.

Answer 3

Can you post some of the libraries that it does link to (from the original system)? You might just need to install some missing libraries.

Typically on a CentOS system it's just a matter of running a yum command like so:

yum install <package name>

You can work backwards from the original system like so:

$ ldd /bin/ls
    linux-vdso.so.1 =>  (0x00007fff519ff000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00000034e8e00000)
    librt.so.1 => /lib64/librt.so.1 (0x00000034e8a00000)
    libcap.so.2 => /lib64/libcap.so.2 (0x0000003d6fe00000)
    libacl.so.1 => /lib64/libacl.so.1 (0x00000034fae00000)
    libc.so.6 => /lib64/libc.so.6 (0x00000034e7200000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00000034e7a00000)
    /lib64/ld-linux-x86-64.so.2 (0x00000034e6e00000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00000034e7e00000)
    libattr.so.1 => /lib64/libattr.so.1 (0x00000034f7600000)

In that output you can see where my copy of /bin/ls is picking up the shared .so libraries for say example, librt.so.1, which happens to be located here: /lib64/librt.so.1.

Knowing this, on the original system, you can run this command to figure out what package provides this library:

$ rpm -qf /lib64/librt.so.1
glibc-2.13-2.x86_64

So the package is called glibc-2.13-2.x86_64. So to install it you'd do this:

$ sudo yum install glibc-2.13-2.x86_64

Answer 4

The answer is in your question: you try to run an application which was compiled for GNU/Linux one year ago and you try to run it with new libraries, which may not be compatible or available anymore.

At this point, you have two choices. If you can recompile it (which I doubt, if I understand well your case), it will run because it will be relinked with compatible libraries. Otherwise, you could try to build a kind of sandbox, an VM running with an old version of GNU libraries for example, to run the application in.

Answer 5

try readelf -l uclsyn_linux Requesting program interpreter will tell you what you missing.

Answer 6

In Arch Linux, if the file is 32-bit elf, you can install lib32-gcc-libs (from multilib repository) to solve the problem.

Answer 7

For completeness, even though it's not the OP's case, but worth noting for people searching reasons of the error in the title: there's also a special type of executable "statically linked". I used to think they still depend on glibc — but apparently they depend on nothing but a kernel. So for example:

 λ cat test.c
int main() {}
 λ gcc test.c -o a -static
 λ file ./a
./a: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=9705bf46ab5eb61fd8d7482d49704856836aeb59, for GNU/Linux 4.4.0, not stripped
 λ ldd ./a
        not a dynamic executable

You can see that file says it's "statically linked".

Answer 8

on Fedora 38 issue with ldd showing not a dynamic executable was solved by installing glibc.i686 package.

after that ldd correctly shows all the dynamically linked libs