CentOS 64 bit bad ELF interpreter

G

9

186

I have just installed CentOS 6 64bit version, I'm trying to install a 32-bit application on a 64-bit machine and got this error:

/lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

How do I resolve this?

Grammarian answered 30/11, 2011 at 15:19 Comment(0)

H

362

You're on a 64-bit system, and don't have 32-bit library support installed.

To install (baseline) support for 32-bit executables

(if you don't use sudo in your setup read note below)

Most desktop Linux systems in the Fedora/Red Hat family:

 pkcon install glibc.i686

Possibly some desktop Debian/Ubuntu systems?:

pkcon install ia32-libs

Fedora or newer Red Hat, CentOS:

 sudo dnf install glibc.i686

Older RHEL, CentOS:

   sudo yum install glibc.i686

Even older RHEL, CentOS:

  sudo yum install glibc.i386

Debian or Ubuntu:

   sudo apt-get install ia32-libs

should grab you the (first, main) library you need.

Once you have that, you'll probably need support libs

Anyone needing to install glibc.i686 or glibc.i386 will probably run into other library dependencies, as well. To identify a package providing an arbitrary library, you can use

 ldd /usr/bin/YOURAPPHERE

if you're not sure it's in /usr/bin you can also fall back on

 ldd $(which YOURAPPNAME)

The output will look like this:

    linux-gate.so.1 =>  (0xf7760000)
    libpthread.so.0 => /lib/libpthread.so.0 (0xf773e000)
    libSM.so.6 => not found

Check for missing libraries (e.g. libSM.so.6 in the above output), and for each one you need to find the package that provides it.

Commands to find the package per distribution family

Fedora/Red Hat Enterprise/CentOS:

 dnf provides /usr/lib/libSM.so.6

or, on older RHEL/CentOS:

 yum provides /usr/lib/libSM.so.6

or, on Debian/Ubuntu:

first, install and download the database for apt-file

 sudo apt-get install apt-file && apt-file update

then search with

 apt-file find libSM.so.6

Note the prefix path /usr/lib in the (usual) case; rarely, some libraries still live under /lib for historical reasons … On typical 64-bit systems, 32-bit libraries live in /usr/lib and 64-bit libraries live in /usr/lib64.

(Debian/Ubuntu organise multi-architecture libraries differently.)

Installing packages for missing libraries

The above should give you a package name, e.g.:

libSM-1.2.0-2.fc15.i686 : X.Org X11 SM runtime library
Repo        : fedora
Matched from:
Filename    : /usr/lib/libSM.so.6

In this example the name of the package is libSM and the name of the 32bit version of the package is libSM.i686.

You can then install the package to grab the requisite library using pkcon in a GUI, or sudo dnf/yum/apt-get as appropriate…. E.g pkcon install libSM.i686. If necessary you can specify the version fully. E.g sudo dnf install ibSM-1.2.0-2.fc15.i686.

Some libraries will have an “epoch” designator before their name; this can be omitted (the curious can read the notes below).

Notes

Warning

Incidentially, the issue you are facing either implies that your RPM (resp. DPkg/DSelect) database is corrupted, or that the application you're trying to run wasn't installed through the package manager. If you're new to Linux, you probably want to avoid using software from sources other than your package manager, whenever possible...

If you don't use "sudo" in your set-up

Type

su -c

every time you see sudo, eg,

su -c dnf install glibc.i686

About the epoch designator in library names

The “epoch” designator before the name is an artifact of the way that the underlying RPM libraries handle version numbers; e.g.

2:libpng-1.2.46-1.fc16.i686 : A library of functions for manipulating PNG image format files
Repo        : fedora
Matched from:
Filename    : /usr/lib/libpng.so.3

Here, the 2: can be omitted; just pkcon install libpng.i686 or sudo dnf install libpng-1.2.46-1.fc16.i686. (It vaguely implies something like: at some point, the version number of the libpng package rolled backwards, and the “epoch” had to be incremented to make sure the newer version would be considered “newer” during updates. Or something similar happened. Twice.)

Updated to clarify and cover the various package manager options more fully (March, 2016)

Hersey answered 30/11, 2011 at 15:33 Comment(4)

iv installed that now im getting libpam.so.0 : cannot open shared object file – Grammarian 30/11, 2011 at 16:4

If your app doesn't list its required libraries, you'll have to hunt them down and install them, yourself; if you're lucky, they'll be available through yum. You can use "ldd (binary)" to list libraries. For each library that is listed, that doesn't give a readout like "/lib/ld-linux.so.2 (0x4f8d9000)" or "libc.so.6 => /lib/libc.so.6 (0x4f8fa000)", try: sudo yum provides */lib/libWHATEVER.so -- to find the package name(s), and then sudo yum install PACKAGE.i686 to install it. (Making sure to grab the i386 or i686, not x86_64 as it would install by default on your system) – Hersey 30/11, 2011 at 17:25

This answer is a Godsend when you have 32-bit software that you must migrate to your 64-bit system. – Curzon 11/3, 2013 at 23:6

This was very helpful for installing Oracle's jre 1.7 on Fedora 20. In addition to glibc.i686, I had to install libgcc.i686. – Oxazine 9/7, 2014 at 19:33

M

18

Just came across the same problem on a freshly installed CentOS 6.4 64-bit machine. A single yum command will fix this plus 99% of similar problems:

yum groupinstall "Compatibility libraries"

Either prefix this with 'sudo' or run as root, whichever works best for you.

Montpellier answered 3/11, 2013 at 23:3 Comment(0)

H

16

In general, when you get an error like this, just do

yum provides ld-linux.so.2

then you'll see something like:

glibc-2.20-5.fc21.i686 : The GNU libc libraries
Repo        : fedora
Matched from:
Provides    : ld-linux.so.2

and then you just run the following like BRPocock wrote (in case you were wondering what the logic was...):

yum install glibc.i686

Haldeman answered 18/1, 2015 at 22:57 Comment(0)

W

4

Try

$ yum provides ld-linux.so.2
$ yum update
$ yum install glibc.i686 libfreetype.so.6 libfontconfig.so.1 libstdc++.so.6

Hope this clears out.

Warmedover answered 16/5, 2017 at 7:24 Comment(0)

C

2

You can also install OpenJDK 32-bit (.i686) instead. According to my test, it will be installed and works without problems.

sudo yum install java-1.8.0-openjdk.i686

Note:

The java-1.8.0-openjdk package contains just the Java Runtime Environment. If you want to develop Java programs then install the java-1.8.0-openjdk-devel package.

See here for more details.

Class answered 1/12, 2018 at 7:5 Comment(0)

O

0

Just wanted to add a comment in BRPocock, but I don't have the sufficient privilegies.

So my contribution was for everyone trying to install IBM Integration Toolkit from IBM's Integration Bus bundle.

When you try to run "Installation Manager" command from folder /Integration_Toolkit/IM_Linux (the file to run is "install") you get the error showed in this post.

Further instructions to fix this problem you'll find in this IBM's web page: https://www-304.ibm.com/support/docview.wss?uid=swg21459143

Hope this helps for anybody trying to install that.

Orville answered 3/12, 2014 at 19:21 Comment(0)

L

0

sudo yum install fontconfig freetype libfreetype.so.6 libfontconfig.so.1 libstdc++.so.6

Leven answered 17/5, 2016 at 9:22 Comment(0)

L

0

I would add for Debian you need at least one compiler in the system (according to Debian Stretch and Jessie 32-bit libraries ).

I installed apt-get install -y gcc-multilib in order to run 32-bit executable file in my docker container based on debian:jessie.

Ladoga answered 22/10, 2017 at 23:57 Comment(1)

please include the essential parts of the link in your answer – Ecg 23/10, 2017 at 0:27

C

0

In my case, I have resolved the issue using command yum install redhat-lsb

Croatia answered 4/9, 2021 at 10:32 Comment(0)