Description of problem: modules compiled with apxs on x86_64 end up in /usr/lib/httpd/modules instead of /usr/lib64/httpd/modules/ Version-Release number of selected component (if applicable): httpd-2.2.2-1.2 How reproducible: this failure is present with various modules from core and extras Steps to Reproduce: 1.install a new fc5 using xenguest-install.py on a x86_64 2.yum install mod_auth_pgsql mod_cband mod_security 3.rpm -ql mod_auth_pgsql mod_cband mod_security | grep modules 4. rpmbuild thoese same three packages 5. rpm -qlp mod_auth_pgsql-2.0.3-2.3.x86_64.rpm mod_cband-0.9.7.3-2.x86_64.rpm mod_security-1.9.4-1.x86_64.rpm | grep modules 6. notice the different directories Actual results: modules are installed in /usr/lib/httpd/modules Expected results: modules in /usr/lib64/httpd/modules Additional info: the same happens to mod_auth_mysql, but that doesnt even build, and has been filed as a seperate bug I ran into this when building a new mod_auth_radius package: Excepts from posting as I wrote it for Fedora Extras: Part of my spec file (which matches other mod_* packages) %build /usr/sbin/apxs -Wc,"%{optflags}" -c mod_auth_radius-2.0.c %install rm -rf %{buildroot} mkdir -p %{buildroot}%{_libdir}/httpd/modules/ mkdir -p %{buildroot}/%{_sysconfdir}/httpd/conf.d/ install -p .libs/mod_auth_radius-2.0.so %{buildroot}/%{_libdir}/httpd/modules/ install -m644 %{SOURCE1} %{buildroot}/%{_sysconfdir}/httpd/conf.d/ relevant bits of output: + cd /usr/src/redhat/BUILD + cd mod_auth_radius-1.5.7 + /usr/sbin/apxs '-Wc,-O2 -g' -c mod_auth_radius-2.0.c /usr/lib64/apr-1/build/libtool --silent --mode=compile gcc -prefer-pic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -pthread -I/usr/include/httpd -I/usr/include/apr-1 -I/usr/include/apr-1 -O2 -g -c -o mod_auth_radius-2.0.lo mod_auth_radius-2.0.c && touch mod_auth_radius-2.0.slo /usr/lib64/apr-1/build/libtool --silent --mode=link gcc -o mod_auth_radius-2.0.la -rpath /usr/lib64/httpd/modules -module -avoid-version mod_auth_radius-2.0.lo + exit 0 Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.599 + umask 022 + cd /usr/src/redhat/BUILD + cd mod_auth_radius-1.5.7 + rm -rf /var/tmp/mod_auth_radius-1.5.7-1-root- + mkdir -p /var/tmp/mod_auth_radius-1.5.7-1-root-/usr/lib/httpd/modules/ + mkdir -p /var/tmp/mod_auth_radius-1.5.7-1-root-//usr/etc/httpd/conf.d/ + install -p .libs/mod_auth_radius-2.0.so /var/tmp/mod_auth_radius-1.5.7-1-root-//usr/lib/httpd/modules/ + install -m644 /usr/src/redhat/SOURCES/mod_auth_radius.conf /var/tmp/mod_auth_radius-1.5.7-1-root-//usr/etc/httpd/conf.d/ + exit 0 As can be seen, apxs seems to reference /usr/lib64/httpd/modules while building, but /var/tmp/mod_auth_radius-1.5.7-1-root-//usr/lib/httpd/modules/ when installing.
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'
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 ***