For my sins, I decided that my new machine should run the 64-bit version of Fedora Core 5. I knew this was going to be somewhat painful, because various important things (such as Flash and Sun's Java) don't yet have 64-bit versions; I was going to have to build 32-bit versions of things like Firefox in order to use them.

Little did I know that Fedora has made it all but impossible to compile a 32-bit version of anything more complicated than a 'Hello World' program. Consider the following simple X11 program, extracted from the configure script for MPlayer:

$ cat testit.c
#include <X11/Xlib.h>
#include <X11/Xutil.h>
int main(void) { (void) XCreateWindow(0,0,0,0,0,0,0,0,0,0,0,0); return 0; }
$ cc -m32 -o testit testit.c -lX11
/usr/bin/ld: skipping incompatible /usr/lib64/libX11.so when searching for -lX11
/usr/bin/ld: cannot find -lX11
collect2: ld returned 1 exit status

The error message is the clue, and here is the problem:

$ echo /usr/lib/libX11.so*
/usr/lib/libX11.so.6 /usr/lib/libX11.so.6.2.0

There should be a /usr/lib/libX11.so symlink that points to the 32-bit libX11 shared library, just like there is a 64-bit libX11.so symlink that ld is helpfully telling us about in the error message (it's part of the libX11-devel RPM). There isn't.

This isn't an isolated incident. On my Fedora Core 5 machine, there are 292 32-bit shared libraries in /usr/lib, from 113 different RPMs; 196 of them don't have the necessary symlink to actually compile 32-bit programs. The broken 32-bit RPMs cover everything from bzip2-libs through readline, including basically all of the X11 and core GTK libraries. (Ironically, the KDE libraries are fine; advantage to KDE again. Not that you'll be compiling many 32-bit KDE programs with the basic X11 libraries unlinkable.)

Unless I'm missing something major, it's pretty clear to me that no one at Red Hat actually tried to build real 32-bit applications under 64-bit Fedora Core 5. I'm not even sure how they built the 32-bit versions of the RPMs they ship as part of the system; I doubt the source RPMs will actually rebuild on a normal 64-bit FC5 machine.

(As an experiment, I tried rebuilding the 32-bit ImageMagick RPM; it blew up more or less on schedule.)

Sidebar: the manual fix

If you want to fix this manually, it's relatively simple: for every affected 32-bit shared library, just go to /usr/lib and symlink libWhat.so to the current version of libWhat.so.blah.blah. The tricky bits are:

1. finding every affected 32-bit library that you care about (usually you find them by having programs fail to link, which is a bit tedious), and
2. figuring out what the current version is. (Fortunately, only a few things have multiple versions of the same shared library.)

I will probably wind up writing some sort of program to do this for me. That I need such a program, and that I need to mangle my system outside of RPMs, irritates the heck out of me.

The better fix presumably starts with a mass bug filing in the Red Hat Bugzilla. The temptation to automate it is strong; after all, I do have curl lying around.