Bug 208059 - %{_libdir} seems broken on x86_64 xeguest-install'ed images
%{_libdir} seems broken on x86_64 xeguest-install'ed images
Status: CLOSED DUPLICATE of bug 233145
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-26 01:59 EDT by Paul Wouters
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-10 15:24:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
rpm output xen0 (30.67 KB, application/octet-stream)
2006-09-26 11:34 EDT, Paul Wouters
no flags Details
rpm output xenu (16.29 KB, application/octet-stream)
2006-09-26 11:36 EDT, Paul Wouters
no flags Details

  None (edit)
Description Paul Wouters 2006-09-26 01:59:15 EDT
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.
Comment 1 Joe Orton 2006-09-26 03:43:15 EDT
apxs is doing the right thing.  Again, your build environment is expanding
%{_libdir} incorrectly.  Please try fedora-list@redhat.com for help!
Comment 2 Paul Wouters 2006-09-26 10:17:59 EDT
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.
Comment 3 Paul Wouters 2006-09-26 10:47:19 EDT
You are correct, %{_libdir} expands wrong for non apxs builds as well. So to
what subsystem should a re-assign this bug?
Comment 4 Paul Wouters 2006-09-26 10:53:08 EDT
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.
Comment 5 Daniel Berrange 2006-09-26 11:18:59 EDT
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'
Comment 6 Daniel Berrange 2006-09-26 11:19:17 EDT
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'
Comment 7 Daniel Berrange 2006-09-26 11:21:03 EDT
Opps, accidentally munged the assigned-to, switching back to xen-maint
Comment 8 Paul Wouters 2006-09-26 11:32:47 EDT
echo x86_64-redhat-linux > /etc/rpm/platform

seemed to fix it (suggestion by Joe Orton <jorton@redhat.com> 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
Comment 9 Paul Wouters 2006-09-26 11:34:31 EDT
Created attachment 137147 [details]
rpm output xen0
Comment 10 Paul Wouters 2006-09-26 11:36:25 EDT
Created attachment 137148 [details]
rpm output xenu
Comment 11 Paul Wouters 2006-09-26 12:05:28 EDT
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.
Comment 12 Daniel Berrange 2006-09-26 12:36:07 EDT
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.
Comment 13 Paul Wouters 2006-09-26 13:05:32 EDT
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.
Comment 14 Paul Wouters 2006-09-26 13:09:19 EDT
Thanks for looking so promptly at this bug report!
Comment 15 Daniel Berrange 2006-09-26 13:17:31 EDT
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.
Comment 16 Jeff Johnson 2007-01-03 12:22:06 EST
This is fixed (by permitting arch to be set from --target) in rpm-4.4.7 and later.

UPSTREAM
Comment 17 David Woodhouse 2007-04-10 15:24:13 EDT

*** This bug has been marked as a duplicate of 233145 ***

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