35

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

12
  • 2
    wild guess: you are trying to run a 32-bit binary on a 64-bit OS without 32-bit libraries installed.
    – michas
    Commented 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
    Commented May 8, 2013 at 11:45
  • 5
    @Carl Out of curiosity, what does strace ./uclsyn output? That may give us an hint about what is missing first.
    – lgeorget
    Commented May 8, 2013 at 13:05
  • @lgeorget, It returns: execve("./uclsyn_linux", ["./uclsyn_linux"], [/* 56 vars */] <unfinished ...> +++ killed by SIGKILL +++
    – Carl
    Commented 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
    Commented May 8, 2013 at 13:12

10 Answers 10

28

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
5
  • 3
    how did you find that that lib was missing ?
    – yehudahs
    Commented Jan 13, 2015 at 12:39
  • 1
    This solution worked for me. +1 Commented 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
    Commented 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 Commented Nov 26, 2018 at 14:29
  • 1
    Works also for me : ldd didn't find something whereas this works ^^
    – jy95
    Commented Apr 9, 2019 at 15:20
10

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.

5

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
3
  • 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
    Commented May 8, 2013 at 11:44
  • Did you yum install <package> those packages that you referenced in your question?
    – slm
    Commented 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
    Commented May 8, 2013 at 12:36
3

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.

5
  • 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
    Commented 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
    Commented 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
    Commented 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
    Commented 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
    Commented May 8, 2013 at 14:43
1

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

1
  • 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
    Commented May 10, 2018 at 16:00
0

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

0

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".

0

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

0

When this happened to me, it turned out that the file was located in a filesystem that was mounted with the noexec option. So the file was executable:

$ ll brio.so
-rwxrwxr-x. 1 xxx xxx 16K Feb  7 11:47 brio.so

but not:

$ test -x brio.so && echo yes || echo no
no

When test -x fails is when ldd reports "not a dynamic executable". Moving the file to another directory that allows execute permissions solved the problem.

SELinux can also cause this, if it blocks files from being executable. Check the output of sealert -l '*' for your filename and a suggested solution.

0

I ran into the error while trying to run ldd on a x86_64 system on a .so file supposedly built for ARM:

$ docker run --rm python:3.8-slim sh -euxc '
  apt-get update;
  apt-get install -y curl unzip;
  curl -O https://files.pythonhosted.org/packages/e7/a1/bd4535ce45ef5853b8e25d2753fe3c89dad419be55d89779ea60a3f52c10/opencv_python_headless-3.4.18.65-cp36-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl;
  unzip opencv_python_headless-3.4.18.65-cp36-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl cv2/cv2.abi3.so;
  ldd cv2/cv2.abi3.so'
...
+ ldd cv2/cv2.abi3.so
        not a dynamic executable

You must log in to answer this question.

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