how Install 32-bit packages on 64-bit Linux red hat 6.2 server
Ideally, you should be able to resolve the problem with these two commands:
yum clean all
yum install glibc.i686
One troubleshooting tip might be to try
yum search libc.so.6
These links might also help:
https://unix.stackexchange.com/questions/156509/an-application-required-libstdc-for-glibcxx-3-4-9-library-on-rhel-5-64bit-syst
https://www.linuxquestions.org/questions/linux-server-73/howto-install-32-bit-libraries-on-64-bit-linux-using-yum-505352/
https://serverfault.com/questions/289400/rhel-6-x64-running-32-bit-applications
==============================================
ADDENDUM:
You posted this additional information:
yum install glibc.i686 Loaded plugins: product-id, security, subscription-manager Updating certificate-based repositories.
No package glibc.i686 available. Error: Nothing to do
This means that none of your currently configured repos happen to have the 32-bit glibc runtime.
If you have the RedHat DVD, try this:
Installing 32 bit libraries (glibc) on 64 bit RHEL without using yum
How to Compile 32-bit Apps on 64-bit RHEL?
To get RHEL 7 64-bit to compile gcc 4.8 32-bit programs, you'll need to do two things.
Make sure all the 32-bit gcc 4.8 development tools are completely installed:
sudo yum install glibc-devel.i686 libgcc.i686 libstdc++-devel.i686 ncurses-devel.i686
Compile programs using the -m32 flag
gcc pgm.c -m32 -o pgm
CentOS 64 bit bad ELF interpreter
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)
Multiple glibc libraries on a single host
It is very possible to have multiple versions of glibc on the same system (we do that every day).
However, you need to know that glibc consists of many pieces (200+ shared libraries) which all must match. One of the pieces is ld-linux.so.2, and it must match libc.so.6, or you'll see the errors you are seeing.
The absolute path to ld-linux.so.2 is hard-coded into the executable at link time, and can not be easily changed after the link is done (Update: can be done with patchelf; see this answer below).
To build an executable that will work with the new glibc, do this:
g++ main.o -o myapp ... \
-Wl,--rpath=/path/to/newglibc \
-Wl,--dynamic-linker=/path/to/newglibc/ld-linux.so.2
The -rpath
linker option will make the runtime loader search for libraries in /path/to/newglibc
(so you wouldn't have to set LD_LIBRARY_PATH
before running it), and the -dynamic-linker
option will "bake" path to correct ld-linux.so.2
into the application.
If you can't relink the myapp
application (e.g. because it is a third-party binary), not all is lost, but it gets trickier. One solution is to set a proper chroot
environment for it. Another possibility is to use rtldi and a binary editor. Update: or you can use patchelf.
Related Topics
What Happens Internally When Deleting an Opened File in Linux
Ssh Service Running on Multiple Ports with Custom Rules in Linux
Nasm Assembly Linux Timer or Sleep
In Bash, How to Expand Variables Twice in Double Quotes
Change a String in a File with Sed
Linux: Find a List of Files in a Dictionary Recursively
Find Based Filename Autocomplete in Bash Script
Webdrivererror Error: Chrome Failed to Start: Exited Abnormally
Write and Read from Ttyusb0, Can't Get Response
Linux - Modify File Modify/Access/Change Time
Why Are Both "True" and "False" Tests True
Make Bash Differentiate Between Ctrl-<Letter> and Ctrl-Shift-<Letter>
Where Does Dmidecode Get The Smbios Table
Driver Ch341 Usb Adapter Serial Port or Qserialport Not Works in Linux