Bug 146718 (IT_72202) - rpm puts x86 binaries in /emul/ia32-linux
Summary: rpm puts x86 binaries in /emul/ia32-linux
Alias: IT_72202
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: rpm   
(Show other bugs)
Version: 4.0
Hardware: ia64
OS: Linux
Target Milestone: ---
: ---
Assignee: Paul Nasrat
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-01-31 23:16 UTC by Hal Prince
Modified: 2007-11-30 22:07 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-30 10:20:54 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 Hal Prince 2005-01-31 23:16:08 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.5)
Gecko/20041109 Firefox/1.0

Description of problem:
We build some rpms on x86 machines, including some 32-bit
binaries (cmds, libraries).  When we install these on an
ia64 machine, rpm places the files in /emul/ia32-linux.
For example, the file that we specify as /sbin/mkfs.vxfs
goes into /emul/ia32-linux/sbin/mkfs.vxfs.  Note that the file
in this example is a 32-bit binary intended to be invoked by
the 64-bit /sbin/mkfs; having it under /emul is not useful.
We need it in /sbin/mkfs.vxfs.  Currently we have changed our
%post scriptlet to link the file into /sbin after rpm has installed
it in /emul.  But is there or could there be some way to get the
old behavior back -- ie, rpm puts the files into the pathnames
specified by the rpm file, with no relocation?  It would be great
if there were some spec file syntax or rpm option to do this.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. create rpm on x86 machine, including 32-bit executable
2.  install this (rpm -ihv *.rpm) on an ia64 machine

Actual Results:  32-bit executables specified as /a/b/c go into

Expected Results:  32-bit executables specified as /a/b/c go into /a/b/c.

Additional info:

Comment 1 Jeff Johnson 2005-02-01 06:26:50 UTC
Relocation for ia32 on ia64 is by directory.

That means that any directory that contains an elf32
binary will be relocated.

There is currently no control of the mechanism, mostly
becuae the intent was to *not* have to teach each i386
package about other platforms, like ia64, where the
package might be installed.

Your case is rather different, because it involves
file system helpers, and your elf64 "kows" that an
elf32 helper is to be invoked.

A symlink from %post is an OK solution (imho), but isn't
a check and exec from /emul/ia32-linux/sbin/mkfs.vxfs
a possible alternative means to deal with the situation?

I'm not sure whether the "old behavior" makes any sense
when talking about mixed elf32/elf64 on same system
(and on the same path). rpm packaging never had to deal
with that case before.

So why can't the /emul/ia32-linux prefixed executable be tested for
and invoked if present?

Comment 2 Hal Prince 2005-02-01 21:33:13 UTC
Thanks very much for your detailed comments, Jeff.

In the case of the 32-bit mkfs.vxfs, the invoking program,
64-bit /sbin/mkfs, is not ours, so we don't control what it does.
But this is just one example.  

Our situation is that we have a certain set of binaries, mostly
commands, that are available on all CPU architectures.  On x86, they
are all 32-bit.  On x86_64 and ia64, some are 32-bit and some are
64-bit.  We want this distinction to be largely invisible, of course,
so we want the commands in the same place on all architectures.  We
have an x86-built "common" rpm with 32-bit binaries, which is loaded
on all architectures.  This rpm says where the binaries should go, and
the rpm command used to put them there, but now it doesn't.

We understand the reason for the autorelocation.  It enables
someone to have both 32-bit and 64-bit versions of the same binary,
and have a reasonable way to access either one.  It's a fine
default, but it doesn't address our situation.

Our current workaround -- symlinking back into the expected
places in the %post scriptlet -- has some disadvantages, principally
that we have to name the files twice, once to itemize them,
and once to symlink them.  It also requires us to write a spec
file with some undesirable knowledge about where the package might be

This is not a serious problem; we filed the bugzilla partly
to be sure we weren't missing some keyword or flag that
would get us the old behavior.  But if you're looking for rpm
suggestions, ours would be to have some spec file syntax that
turns off autorelocation, so the files go where the spec file
says.  We're guessing that others would find this useful as well.

Comment 3 Jay Turner 2005-02-03 12:12:54 UTC
Peripherally related . . . just make to make you aware that RHEL4 on IA64 has no
ability to execute 32-bit code until the ia32el package is installed and the
service started (which happens automatically as part of installation.)

Comment 4 Sachin 2005-02-08 08:28:52 UTC
Intresting thing is that it does not relocate the binaries created on 
Redhat Advanced Server 2.1-32 bit.( because _autorelocate_path macro 
is not defined )
Is there is any way to avoid autorelocation ?

Comment 5 Hal Prince 2005-04-18 20:18:03 UTC
We have discovered that "AutoReqProv: no" will turn off this
relocation.  Is this a reasonable way to disable it?
I'm guessing not, but thought I would ask anyway.

Comment 6 Paul Nasrat 2005-11-28 21:06:19 UTC
AutoReqProv: no would preventing rpm marking the provides of binaries, on ia64
this would put binaries in / however they will not be able to execute as later
ia64 do not natively run x86 instructions.

For something like mkfs where you are plugging into an existing framework of
extensions on itanium you should provide ia64 binaries.

Comment 7 Paul Nasrat 2006-10-30 10:20:54 UTC
RPM relocation for x86 on ia64 is working as designed due to the need to have an
emulation layer. 

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