Bug 146155
Summary: | rpmbuild --target ppc64 builds ppc32 binaries | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | David Lehman <dlehman> |
Component: | rpm | Assignee: | Panu Matilainen <pmatilai> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3.0 | CC: | dwmw2, nobody+pnasrat, sundaram, tao |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | powerpc | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-10-19 19:08:47 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 150223 |
Description
David Lehman
2005-01-25 18:33:28 UTC
Yep. Edit /etc/rpm/platform, substitute s/ppc/ppc64/, as work around. NEEDINFO until feature is prioritized, as rpmbuild has never promised the ability for multi-arch builds by (original, but now creaky) design. That doesn't do it for me. My /etc/rpm/platform already had something like ppc64pseries-redhat-linux in it, so rpm more or less knew it was a 64-bit platform. The problem is that even /usr/lib/rpm/ppc64-redhat-linux/macros doesn't include -m64 in optflags, which AFAICT is absolutely needed to get 64-bit binaries on ppc64 RHEL. Adding it fixes most packages, but not all. Certainly in some of those cases it's because the package blindly does things like 'gcc -shared ...' THe first sentence of the last paragraph from Comment 2 should read: "Adding -m64 to optflags fixes most packages, but not all" Do you have the redhat-rpm-config package installed? Yes, I reinstalled the box when I started on this issue and made sure to include all the architecture compatibility comps. At some point I got curious and verified the install included redhat-rpm-config-8.0.28-2. Using "setarch" might also help to get the right target setup? This is still not working right -- and it means that RHEL and Fedora aren't self-hosting. We should at least put -m64 into ppc64 optflags, I think -- {how,} does this work for i386 vs. x86_64? I just tried on rawhide cat /etc/rpm/platform ppc64pseries-redhat-linux rpm -E '%optflags' rpm -ivh /mnt/redhat/rawhide-ppc/SRPMS/bc-1.06-19.2.1.src.rpm rpmbuild --target ppc64 bc.spec cd ../BUILD/bc-1.06/bc bc: ELF 64-bit MSB executable, cisco 7500, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped I tried on rawhide [root@dhcp78-22 SPECS]# cat /etc/issue Fedora Core release 4.92 (Pre-FC5) Kernel \r on an \m [root@dhcp78-22 SPECS]# [root@dhcp78-22 SPECS]# rpmbuild -bb --target ppc64 ./bc.spec [root@dhcp78-22 SPECS]# file ../BUILD/bc-1.06/bc/bc ../BUILD/bc-1.06/bc/bc: ELF 64-bit MSB executable, cisco 7500, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped [root@dhcp78-22 SPECS]# Also, tried with --target ppc to build 32bit binaries... [root@dhcp78-22 SPECS]# rpmbuild -bb --target ppc ./tar.spec [root@dhcp78-22 SPECS]# file ../BUILD/tar-1.15.1/src/tar ../BUILD/tar-1.15.1/src/tar: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped [root@dhcp78-22 SPECS]# OK %_libdir is still busted CFLAGS are correct. This problem is likely fixed (by setting arch from --tqarget) in rpm-4.4.7-0.15 UPSTREAM This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you. |