Red Hat Bugzilla – Bug 590416
Cross compile from x86_64 to x86 builds 64 bit utilities instead of 32 bit
Last modified: 2010-06-28 11:44:20 EDT
Description of problem: A 'rpmbuild --target i586' builds a few utilities in kernel-devel that are 64 bit and not 32 bit. This causes utilities such as systemtap to fail.
Version-Release number of selected component (if applicable): kernel-220.127.116.11-105.2.23.fc11
How reproducible: 100%
Steps to Reproduce:
1. rpmbuild --target i586 -bb kernel.spec # done on x86_64 host
Actual results: The following files are compiled as 64bit:
hostprogs-y := modpost mk_elfconfig
hostprogs-y := fixdep docproc hash
"=== 4 Host Program support
Kbuild supports building executables on the host for use during the
Two steps are required in order to use a host executable.
The first step is to tell kbuild that a host program exists. This is
done utilising the variable hostprogs-y."
IOW these are explicitly built for the host, not the target, in the upstream makefiles.
Why does systemtap care about things like fixdep and modpost?
systemtap builds a kernel module for the instrumentation. One can see the "make -C ..." when using the "stap -vv ..." The fixdep and modpost are called during the build of the systemtap instrumentation kernel module.
It might be wiser to use mock to build the kernel in a chroot environment to ensure that everything is really 32-bit.
Ok, so I guess there are different requirements for these tools; when building for a package, we want the build host to do the processing of the things that will be packaged. However, if we are actually packaging those tools themselves, we want them to be built for the target. Hrm. Probably not an easy one to fix... using Mock sounds good :)
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.