32 bit builds on 64 bit CentOS 5 hosts

32bit-64bitcentosgccvalgrindyum

I am trying to build valgrind (3.7.0) on a 64 bit host (running CentOS 5.8). I need to use valgrind in examining the performance of a 32 bit program (built on a 32 bit host, I need 32 bit because the program needs to run on 32 bit and 64 bit hosts).

The problem is that my 64 bit host did not have gcc, so I installed gcc using "sudo yum install gcc" with the Stanford University repo mirror (the default repos for this 64 bit host were unavailable and thus yum was timing out). This allowed me to build valgrind, and it worked for local stuff (e.g. "valgrind ls -l"), but failed when trying to run it for the 32 bit program I have built on another host. I finally figured out that the configure script for valgrind was detecting that I did not have 32 bit build support on the host (by running "configure –enable-only32bit" which reported "checking for 32 bit build support… no").

So how do I get 32 bit support for gcc, etc? I tried "yum search gcc | grep i386" and then installing whatever looked like 32 bit C stuff ("sudo yum install compat-glibc.i386 compat-libgcc-296.i386 compat-libstdc++-296.i386 compat-libstdc++-33.i386 libgcc.i386 libstdc++.i386 libstdc++-devel.i386 libstdc++44-devel.i386 edac-utils.i386 edac-utils.x86_64 nspluginwrapper.i386") but "configure –enable-only32bit" still reports no 32 bit support.

PS: The yum.conf looks pretty minimal, i.e. no excludes. The only odd thing in it is "installonly_limit = 5"

OK, here is the scoop, thanks to Error "gnu/stubs-32.h: No such file or directory" while compiling Nachos source code

The short answer is to install glibc-devel.i386 (on CentOS 5.8 anyway… for different distros it has different names, e.g. glibc-devel.i686, libc6-dev-i386, etc), possibly in addition to the other packages I listed above (I did not uninstall those to see if glibc-devel.i386 was sufficient by itself).

I arrived at the right question to search for by examining the configure script and seeing that it tries to compile a minimal C program with "-m32" and if that fails then the configure script reports "no 32 bit support". So I created the classic HelloWorld C program and compiled it ("cc -m32 hello.c"). This complained of a missing header file "gnu/stubs-32.h". So a google search on "what package has gnu/stubs-32.h" took me to the stackoverflow page I cite above.

Best Answer

Try:

yum install glibc-devel.i686

if this doesn't work then check this solution: How to compile a 32-bit binary on a 64-bit linux machine with gcc/cmake

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)

Building a 32-bit app in 64-bit Ubuntu

You need to use link with -m32 as well.

gcc -m32 -o xgap xcmds.o utils.o gapgraph.o gaptext.o pty.o popdial.o xgap.o selfile.o   -L/usr/lib32 -lXaw -lXmu -lXt -lXext -lX11  -lSM -lICE

All things considered, I think you should be able to drop the -L/usr/lib32 when using -m32.