Bug 208059
Summary: | %{_libdir} seems broken on x86_64 xeguest-install'ed images | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Paul Wouters <pwouters> | ||||||
Component: | rpm | Assignee: | Paul Nasrat <nobody+pnasrat> | ||||||
Status: | CLOSED DUPLICATE | QA Contact: | |||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 5 | CC: | bstein, katzj | ||||||
Target Milestone: | --- | Keywords: | Reopened | ||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2007-04-10 19:24:13 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: | |||||||||
Attachments: |
|
Description
Paul Wouters
2006-09-26 05:59:15 UTC
apxs is doing the right thing. Again, your build environment is expanding %{_libdir} incorrectly. Please try fedora-list for help! Please do not be so trigger happy closing bugs. As stated, this is a STOCK FC5 xen0/xenU xenguest-install.py install on an x86_64 machine. If the build environment is broken, this is a REAL BUG, and not due to some of my personal systme's specific, because there are none. Since the other bug seems related to this one, I will leave that bug closed. You are correct, %{_libdir} expands wrong for non apxs builds as well. So to what subsystem should a re-assign this bug? It seems the stock FC5 xenguest-install.py on x86_64, despite running the proper 64bit kernel/userland, is somehow using /usr/lib as %{_libdir}. This is odd, as it is a virgin xenguest install from a x86_86 xen0, where the xen0 properly expands %{_libdir} to /usr/lib64. Changing this bug to the xen package. I've just tested the following on a Fedora Core 5 guest installed with xenguest-install.py on x86_64: [root@dhcp-5-248 ~]# cat demo.spec Summary: Demo Name: demo Version: 1.0 Release: 1 License: GPL Group:Demo URL: http://demo.org/ BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root %description %prep echo %{_libdir} [root@dhcp-5-248 ~]# rpmbuild -bp demo.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.92552 + umask 022 + cd /usr/src/redhat/BUILD + echo /usr/lib64 /usr/lib64 + exit 0 So it looks like %{_libdir} is getting expanded correctly. Can you post versions (and architecture) of the 'rpm' and 'rpm-build' scripts, and 'uname -a'. Or even just dump the whole RPM DB 'rpm --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' -qa' I've just tested the following on a Fedora Core 5 guest installed with xenguest-install.py on x86_64: [root@dhcp-5-248 ~]# cat demo.spec Summary: Demo Name: demo Version: 1.0 Release: 1 License: GPL Group:Demo URL: http://demo.org/ BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root %description %prep echo %{_libdir} [root@dhcp-5-248 ~]# rpmbuild -bp demo.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.92552 + umask 022 + cd /usr/src/redhat/BUILD + echo /usr/lib64 /usr/lib64 + exit 0 So it looks like %{_libdir} is getting expanded correctly. Can you post versions (and architecture) of the 'rpm' and 'rpm-build' scripts, and 'uname -a'. Or even just dump the whole RPM DB 'rpm --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' -qa' Opps, accidentally munged the assigned-to, switching back to xen-maint echo x86_64-redhat-linux > /etc/rpm/platform seemed to fix it (suggestion by Joe Orton <jorton> from xen list) Indeed, it looks like the xen0 and xenu both had "ia32e-redhat-linux". For the xen0, that did not matter, it still build for /usr/lib64/, but for the xenU it did matter, it build for /usr/lib. I confirmed from my collegue that the CD's used were the 64bit CD's. uname's from xenU and xen0: # uname -a Linux untappable.xtdnet.nl 2.6.17-1.2187_FC5xenU #1 SMP Mon Sep 11 02:07:52 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux # uname -a Linux unbearable.xtdnet.nl 2.6.17-1.2187_FC5xen0 #1 SMP Mon Sep 11 01:51:30 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux rpm output attached as rpm-xenu.out and rpm-xen0.out Created attachment 137147 [details]
rpm output xen0
Created attachment 137148 [details]
rpm output xenu
As a side note to this bug, i have another issue with 32/64 where I put a xen2 rootfs image onto this same xen3 x86_64 xen0, and there rpm wants to install x86_64 packages instead of 32bit packages. There the /etc/rpm/platform file also has ia32e-redhat-linux, and it was running the same x86_64 xenu kernel as the system above. so it seems I got into issues both ways. 64bit not staying 64bit amd 32bit userland not staying 32bit. So 'ia32e-redhat-linux' is actually the correct setting for an Intel x86_64 box since that's the canonical arch name for Intel CPUs - x86-64-redhat-linux is only used for AMD CPUs. The problem is that RPM is not interpreting ia32e as being a 64-bit architecture and thus needing /usr/lib64. I'm not entirely clear how/why, but empirically this is solved by installing the redhat-rpm-config RPM which installs a bunch of extra macros for rpm/rpmbuild to use. Please close this bug if installing 'redhat-rpm-config' is an acceptable solution. If not it'll need to be reassigned to 'rpm' since its not a xen bug. Yes, that worked. I changed back /etc/rpm/platform to 'ia32e-redhat-linux', and yum installed redhat-rpm-config on the xenU. This package was already installed on the xen0, which explains the difference. So is this a bug in xenguest-install.py (thus the xen package). It should add redhat-rpm-config to the base guest system. Or a bug in rpm, for not including it in a base system? If you change either the xen or rpm package to include the redat-rpm-config package, then you can consider this bug resolved. Thanks for looking so promptly at this bug report! redhat-rpm-config is not a requirement of either Xen or RPM so adding it as a dependancy is inappropriate. I suspect the reason its present on your Dom0 is simply that you did an 'full' install during initial provisioning, vs a more minimal install for the DomU. I'm going to re-assign to rpm to see if they consider fixing ia32e to use /usr/lib64 in the standard base RPM macros is reasonable. This is fixed (by permitting arch to be set from --target) in rpm-4.4.7 and later. UPSTREAM *** This bug has been marked as a duplicate of 233145 *** |