Bug 469049 - rpm builds ppc64 packages incorrectly
rpm builds ppc64 packages incorrectly
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: rpm (Show other bugs)
5.2.z
powerpc Linux
medium Severity medium
: rc
: ---
Assigned To: Panu Matilainen
BaseOS QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-29 13:31 EDT by Mike McLean
Modified: 2009-01-21 05:06 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-21 05:06:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace of rpm --showrc in a 5.2 chroot on a rhel4 host (45.14 KB, text/plain)
2008-10-29 14:08 EDT, Mike McLean
no flags Details
strace of rpm --showrc in a 5.2 chroot on a rhel5 host (37.19 KB, text/plain)
2008-10-29 14:09 EDT, Mike McLean
no flags Details

  None (edit)
Description Mike McLean 2008-10-29 13:31:00 EDT
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
Comment 1 Mike McLean 2008-10-29 13:38:26 EDT
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.
Comment 2 Mike McLean 2008-10-29 14:05:17 EDT
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
Comment 3 Mike McLean 2008-10-29 14:08:31 EDT
Created attachment 321839 [details]
strace of rpm --showrc in a 5.2 chroot on a rhel4 host
Comment 4 Mike McLean 2008-10-29 14:09:04 EDT
Created attachment 321840 [details]
strace of rpm --showrc in a 5.2 chroot on a rhel5 host
Comment 7 Mike McLean 2008-10-29 16:13:52 EDT
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.
Comment 9 Mike McLean 2008-10-30 13:14:53 EDT
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.
Comment 10 Panu Matilainen 2009-01-21 05:06:44 EST
As per comment #9, this is fixed in RHEL 5.3.

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