Red Hat Bugzilla – Bug 146718
rpm puts x86 binaries in /emul/ia32-linux
Last modified: 2007-11-30 17:07:16 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.5)
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):
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.
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?
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.
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.)
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 ?
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.
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.
RPM relocation for x86 on ia64 is working as designed due to the need to have an