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-2.6.30.10-105.2.23.fc11 How reproducible: 100% Steps to Reproduce: 1. rpmbuild --target i586 -bb kernel.spec # done on x86_64 host 2. 3. Actual results: The following files are compiled as 64bit: /usr/src/kernels/2.6.30.10-105.2.23.fc11.i586/scripts/basic/fixdep /usr/src/kernels/2.6.30.10-105.2.23.fc11.i586/scripts/basic/hash /usr/src/kernels/2.6.30.10-105.2.23.fc11.i586/scripts/mod/modpost Expected results: Additional info:
scripts/mod/Makefile: hostprogs-y := modpost mk_elfconfig scripts/basic/Makefile: hostprogs-y := fixdep docproc hash "=== 4 Host Program support Kbuild supports building executables on the host for use during the compilation stage. 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. http://fedoraproject.org/wiki/Projects/Mock
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.