32

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

Anthon
  • 78,313
  • 42
  • 165
  • 222
Carl
  • 521
  • 1
  • 4
  • 10
  • 2
    wild guess: you are trying to run a 32-bit binary on a 64-bit OS without 32-bit libraries installed. – michas May 08 '13 at 00: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 08 '13 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 08 '13 at 13:05
  • @lgeorget, It returns: execve("./uclsyn_linux", ["./uclsyn_linux"], [/* 56 vars */] +++ killed by SIGKILL +++ – Carl May 08 '13 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 08 '13 at 13:12
  • @lgeorget So does this mean it's a different issue and perhaps not a missing library? – Carl May 08 '13 at 13:17
  • @Carl IMO, it's unlikely as it did run on a similar system with the only difference being a minor revision in the kernel. And the output of `ldd` shows that there is a problem with linking. – lgeorget May 08 '13 at 13:20
  • @lgeorget Your comment actually helped. I did a search for "strace killed by sigkill" and found that someone else had an issue related to memory. I checked the RAM allocation, upped it to 1024Mb and now it runs nicely. I feel so stupid! – Carl May 08 '13 at 13:25
  • @Carl Good for you then! Glad to have being wrong supposing it was a matter of linking! :D Now the question is: why does `ldd` output that the program is not dynamically linked whereas `file` shows the opposite. Feel free to post your own answer and accept it so that others users with the same issue found it easily. – lgeorget May 08 '13 at 13:29
  • @lgeorget Surprisingly, now running ldd on that executable returns the correct list of libraries. Go figure! – Carl May 08 '13 at 13:46
  • let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/8678/discussion-between-lgeorget-and-carl) – lgeorget May 08 '13 at 13:53
  • @Carl, What's the line containing ld-linux on the output of `ldd` in the machine where it works? And does this file exist in you new installation? – Frederik Deweerdt May 08 '13 at 14:28

8 Answers8

26

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
kungfooman
  • 361
  • 3
  • 3
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.

Carl
  • 521
  • 1
  • 4
  • 10
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
slm
  • 363,520
  • 117
  • 767
  • 871
  • 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 08 '13 at 11:44
  • Did you `yum install ` those packages that you referenced in your question? – slm May 08 '13 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 08 '13 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.

lgeorget
  • 13,656
  • 2
  • 41
  • 63
  • 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 08 '13 at 03: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 08 '13 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 08 '13 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 08 '13 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 08 '13 at 14:43
0

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

netawater
  • 111
  • 2
  • 1
    I ran `readelf -l ` 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 '18 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.

Ashark
  • 767
  • 7
  • 24
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".

Hi-Angel
  • 4,778
  • 4
  • 28
  • 45
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

scorpp
  • 181
  • 1
  • 2