Description of problem: On a ppc64 5.2 host (uname -m reports ppc64), when /etc/rpm/platform is absent, rpm picks a build arch of ppc. Furthermore, even if --target ppc64 is passed to rpmbuild, %{_libdir} is still set to /usr/lib. This was first noticed in a chroot building environment. The maddening thing is that if I create identical RHEL5.2 chroot environments and use one on a RHEL4 host and the other on a RHEL5 host, the results are different. On the RHEL4 host, rpm --showrc (run in the chroot) will show ppc64. On the RHEL5 host, it shows ppc instead. Version-Release number of selected component (if applicable): rpm-4.4.2-48.el5
To see the %{_libdir} issue, you don't need a chroot, just a 5.2 box. run rpm -bp foo.spec using this spec: ----- Name: foo Version: 1.0 Release: 1 Summary: foo License: GPL Group: System Environment/Base %description foo %prep echo _libdir is: %{_libdir} echo _target_cpu is: %{_target_cpu} echo _target_os is: %{_target_os} ----- I suppose one can argue about the correct default build target on RHEL ppc, but building ppc64 packages with _libdir=/usr/lib is wrong.
The really aggravating thing for me is that fact that this works correctly when the host os outside the chroot is RHEL4. Create a 5.2 ppc64 chroot on a RHEL4 host, chroot in and rpm --showrc reports a what I expect. If I rsync that chroot to a RHEL5 host and try again, I get a ppc result. In both cases uname -m (and -p and -i) report ppc64. I've straced both runs and compared the results. It seems to me that with identical chroots, the difference much some from a system call somewhere. In the RHEL4 chroot I ran: % strace -o /tmp/foo1.st rpm --showrc Similarly, in the RHEL5 one, I ran: % strace -o /tmp/foo2.st rpm --showrc To compare them, I filtered out some noisy address/timestamp-ridden calls: % egrep -v '^mmap|^mprotect|^gettimeofday|^rt_sigaction|^munmap' /tmp/foo1.st >/tmp/foo1.x % egrep -v '^mmap|^mprotect|^gettimeofday|^rt_sigaction|^munmap' /tmp/foo2.st >/tmp/foo2.x The diff of foo{1,2}.x is does not show much difference before the point where one opens /usr/lib/rpm/ppc64-linux/macros and the other /usr/lib/rpm/ppc-linux/macros. Before this point, the significant differences seem to be: - on the RHEL4 host, uname gets called immediately at startup. The RHEL5 host does not call uname at this point (both call it later after failing to open /etc/rpm/platform). - on the RHEL4 host, the later uname call is followed by a SIGILL. On the RHEL5 host, no such signal occurs. I'll attach the straces
Created attachment 321839 [details] strace of rpm --showrc in a 5.2 chroot on a rhel4 host
Created attachment 321840 [details] strace of rpm --showrc in a 5.2 chroot on a rhel5 host
So, I think the SIGILL is the telling difference, this must come from line 1334 in lib/rpmrc.c: 1331 unsigned pvr = 0; 1332 __sighandler_t oldh = signal(SIGILL, mfspr_ill); 1333 if (setjmp(mfspr_jmpbuf) == 0) { 1334 __asm__ __volatile__ ("mfspr %0, 287" : "=r" (pvr)); 1335 } 1336 signal(SIGILL, oldh); 1337 1338 if ( pvr ) { 1339 pvr >>= 16; 1340 if ( pvr >= 0x40) 1341 strcpy(un.machine, "ppcpseries"); 1342 else if ( (pvr == 0x36) || (pvr == 0x37) ) 1343 strcpy(un.machine, "ppciseries"); 1344 else 1345 strcpy(un.machine, "ppc"); 1346 } This seems to be a test to distinguish between various flavors of ppc, but it fails to account for 32bit vs 64bit. I guess mfspr instruction must fail under the rhel4 kernel.
yes, rpm-4.4.2.3-5.el5 appears to fix this issue. Another workaround is to stick an /etc/rpm/platform in the chroot.
As per comment #9, this is fixed in RHEL 5.3.