From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041109 Firefox/1.0 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): perl-5.8.5-9 How reproducible: Always Additional info: https://www.redhat.com/archives/fedora-devel-list/2004-January/msg01206.html One year later, I have one such example for Chip. Am I the first to report this?
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 notes). 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 /usr/bin/bdf2gdfont.pl...
I suppose the clarification is that you are out of luck, unfortunately; there's really no way to sanely package compatibility in this case.