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

$ 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

  • 2
    wild guess: you are trying to run a 32-bit binary on a 64-bit OS without 32-bit libraries installed.
    – michas
    May 8, 2013 at 0:18
  • It is a 32-bit binary, but the OS I installed is the 32-bit version of CentOS. At least that's what the uname-a command tells me yes?
    – Carl
    May 8, 2013 at 11:45
  • 4
    @Carl Out of curiosity, what does strace ./uclsyn output? That may give us an hint about what is missing first.
    – lgeorget
    May 8, 2013 at 13:05
  • @lgeorget, It returns: execve("./uclsyn_linux", ["./uclsyn_linux"], [/* 56 vars */] <unfinished ...> +++ killed by SIGKILL +++
    – Carl
    May 8, 2013 at 13:09
  • @Carl Ok, so it doesn't even go to the point at which it tries to load some libraries. I've never tried before to strace a program not correctly linked.
    – lgeorget
    May 8, 2013 at 13:12

6 Answers 6


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
  • 3
    how did you find that that lib was missing ?
    – yehudahs
    Jan 13, 2015 at 12:39
  • 1
    This solution worked for me. +1 Jan 15, 2015 at 18:59
  • 2
    @yehudahs I've run lots of precompiled 32bit applications on Linux for quite a while plus Reverse Engineering them, so I collected some trouble shooting experiences. :D
    – kungfooman
    Aug 7, 2016 at 4:46
  • 1
    nice this worked for me as well as i was scratching my head what i was doing wrong Nov 26, 2018 at 14:29
  • 1
    Works also for me : ldd didn't find something whereas this works ^^
    – jy95
    Apr 9, 2019 at 15:20

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.


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

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
  • Thanks so much for the help. I'm getting further. Have updated my question with some more info now, if you want to update your response with the same it would be much appreciated. :)
    – Carl
    May 8, 2013 at 11:44
  • Did you yum install <package> those packages that you referenced in your question?
    – slm
    May 8, 2013 at 11:58
  • Yes I did. They were all installed except for libuuid.i686 which is now, but I still have the same problem.
    – Carl
    May 8, 2013 at 12:36

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.

  • 1
    This is not correct. The program is statically linked, no libraries on the host system are going to be referenced. While the ABI may still cause incompatibility, it's unlikely between minor revs of linux kernel (assuming same architecture).
    – ckhan
    May 8, 2013 at 3:37
  • 1
    It's not statically linked, see the output from file. And messages like No package xyz found suggest that the needed libraries are no longer available (at least, not the way they were, in the same packages). That's why I suggest rebuilding the program, if it's possible, or running it in a system in which it was known to work, with old libraries.
    – lgeorget
    May 8, 2013 at 12:03
  • Unfortunately recompiling isn't an option here. I got it running on another system just in the same way I'm trying here, but for some reason, this time it doesn't like it.
    – Carl
    May 8, 2013 at 13:11
  • This is wrong. Addresses changing does not matter at all. Functions being removed or other ABI breaks happen at major revisions of the library ( which are rare ), in which case, you would get an error loading libfoo2 if you don't have libfoo2 installed, whether or not you have libfoo3 installed.
    – psusi
    May 8, 2013 at 14:23
  • Ok, good to know. I thought that any change in a library could break the linking. I am currently running a gentoo and I often have to recompile the reverse dependencies when I upgrade a library, so I didn't think linking was so resistant to library changes.
    – lgeorget
    May 8, 2013 at 14:43

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

  • 1
    I ran readelf -l <file> against a file with the same ldd behaviour (not a dynamic executable), but I don't see anything immediately indicating a missing library. I see Elf file type is EXEC (Executable file), Entry point, Program Headers and Section to Segment mapping. What exactly should I look for in the output?
    – StockB
    May 10, 2018 at 16:00

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

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.