Bug 145586

Summary:	x86_64's perl.i386 does not include a 32bit interpreter
Product:	[Fedora] Fedora	Reporter:	Rudi Chiarito <nutello>
Component:	perl	Assignee:	Chip Turner <cturner>
Status:	CLOSED WONTFIX	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3	CC:	davide.rossetti, notting
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-01-21 04:45:00 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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):
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?

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
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...

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.