Bug 145586 - x86_64's perl.i386 does not include a 32bit interpreter
Summary: x86_64's perl.i386 does not include a 32bit interpreter
Alias: None
Product: Fedora
Classification: Fedora
Component: perl   
(Show other bugs)
Version: 3
Hardware: x86_64 Linux
Target Milestone: ---
Assignee: Chip Turner
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2005-01-19 22:05 UTC by Rudi Chiarito
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-21 04:45:00 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Rudi Chiarito 2005-01-19 22:05:50 UTC
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):

How reproducible:

Additional info:

One year later, I have one such example for Chip. Am I the first to
report this?

Comment 1 Bill Nottingham 2005-01-21 04:45:00 UTC
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.

Comment 2 Rudi Chiarito 2005-01-29 17:56:02 UTC
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

Comment 3 Bill Nottingham 2005-01-31 20:30:27 UTC
I suppose the clarification is that you are out of luck,
unfortunately; there's really no way to sanely package compatibility
in this case.

Note You need to log in before you can comment on or make changes to this bug.