From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
I guess this hasn't been reported yet because it is very rare for
someone to need to start a 32-bit perl interpreter, but if you use
a module that links to a binary-only 32-bit shared library, you are
out of luck. Of course, I have seen this in real life.
The x86_64 tree ships with a perl.i386 RPM, whose usefulness I do not
understand. It has all the 32-bit libraries, but the main
/usr/bin/perl executable is shared with the x86_64 package: it's thus
a 64-bit binary and will refuse (rightly so) to link against a 32-bit
library. Maybe a 32-bit mod_perl can make use of the 32-bit perl .so
libraries? No idea.
Anyway, I think for those unlucky cases like mine where 32-bit
compatibility is occasionally needed, it might make sense to ship a
32bit binary - named /usr/bin/perl32, maybe? It looks like most of the
work/time involved in building a full-fledged 32bit perl package is
already there (for the libraries)...
I grabbed the perl interpreter from a 32bit FC3 box, copied it to the
64-bit box as /usr/bin/perl32, replaced the paths in all the CGI
scripts and - voila' - the problem was circumvented for the time
being. Of course, it would be nice to be able to avoid such crude hacks.
Version-Release number of selected component (if applicable):
One year later, I have one such example for Chip. Am I the first to
Having a perl32 doesn't really make the packaging sane for using the
same i386 package on x86-64.
To be honest, 32-bit perl was mistakenly included on x86-64; we did
not catch that it didn't work as expected before we shipped. It will not
be in future updates for FC3, nor will it be shipped that way in FC4.
Closing as WONTFIX, because of this.
For the record, then, what are users expected to do if they have
modules that are linked to native 32-bit binary-only libraries? I
think this deserves a clarification (if not a statement in the release
Again, am I the only person who has seen this? I know that it totally
sucks. On the other hand, I can understand how this can lead to big
trouble - e.g. try 32 and 64 bit versions of the third-party perl-GD
package at the same time: chances are that both try to install
I suppose the clarification is that you are out of luck,
unfortunately; there's really no way to sanely package compatibility
in this case.