Bugzilla Bug 81982

emerge info:

Portage 2.0.51-r15 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.11-rc3 x86_64)
=================================================================
System uname: 2.6.11-rc3 x86_64 AMD Athlon(tm) 64 Processor 3400+
Gentoo Base System version 1.6.9
Python:              dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 12 2005, 10:08:41)]
distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
ccache version 2.3 [enabled]
dev-lang/python:     2.3.4-r1
sys-devel/autoconf:  2.59-r6, 2.13
sys-devel/automake:  1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4
sys-devel/binutils:  2.15.92.0.2-r1
sys-devel/libtool:   1.5.10-r4
virtual/os-headers:  2.6.8.1-r4
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CFLAGS="-march=k8 -fomit-frame-pointer -O3 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=k8 -fomit-frame-pointer -O3 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache cvs digest distlocks sandbox"
GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/"
LANG="en_US.UTF-8"
LDFLAGS="-Wl,-O1"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/home/heino/projects/gentoo/cvs/gentoo-x86"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 X acpi alsa berkdb bitmap-fonts cdr crypt cups dvd esd f77 fam fortran gif gnome gpm gstreamer gtk gtk2 hal imagemagick imlib java jp2 jpeg kde lirc lm_sensors lzw lzw-tiff mad motif mozilla ncurses nls nptl oggvorbis opengl oss pam perl png python qt readline samba slang ssl svg tcpd tiff truetype truetype-fonts type1-fonts unicode usb userlocales xml2 xpm xrandr xv zlib"
Unset:  ASFLAGS, CBUILD, CTARGET, LC_ALL

Created an attachment (id=51199) [details]
rpm-4.2.1.log

Something is weird with lib/lib64/lib6464

I'm having the same problem.. gotta be an AMD64 issue.

Created an attachment (id=55249) [details]
patch for rpm-4.2.1 to work with Gentoo lib64 configuration settings

I have attached a patch I created, which appears to fix this problem.  I was
able to successfully emerge rpm-4.2.1 on amd64 with this patch.  Additional
testing would be beneficial, but it has worked well for me so far.

I tested on amd64 with the above patch, and it installs and works fine.  I
tried to test on x86, but I can't get beecrypt to install.

Same problem here.  I encountered it while doing an "emerge -e world".

addition to comment #6:

Encountered problem while doing "emerge -e world" after updated profile from 2004.3 to 2005.0

thanks for the patch, i applied it and worked here -> In cvs

I've reverted this patch in portage which breaks run-time on all platforms:

$ rpm
error: Unable to open ${exec_prefix}/lib/rpm/rpmrc for reading: No such file or directory.

Please don't apply patches without a revbump and ~arch marking.  And please fix this patch before doing that...

The original patch works as submitted for amd64.  However, I have verified that
it does cause the
breakage described by agriffis on x86 and ppc, and possibly others.  This is
due to the fact that the
original patch depends on --libdir being passed to the configure script, which
is true for the amd64
profile.  (The amd64 profile passes --libdir=/usr/lib64 to configure.) 
However, this assumption is not
true for profiles used on other platforms.

I am submitting a modified patch that takes this into account.  This patch has
been tested on both ppc
and amd64, and verified to fix the original problem on amd64 without breaking
other arches like ppc.  I
would propose making a new ebuild that uses this patch, and keywording it with
~ for testing.

Sorry for the inconvenience -- I will be more diligent about testing changes on
other arches in the 
future.

Created an attachment (id=58643) [details]
modified rpm-4.2.1 patch to fix amd64 libdir issue without breaking other
arches

you could still improve you patch

a. which did you put the whole configure.orig file in there
b. you should probably have a test like
if test  "${libdir}; then stuff with libdir; else stuff with prefix; fi
c. you still use libdir in the Makefile.in .. is that OK ?

Many thanks for taking the time to review the patch and making suggestions.  I
would like to address your points in turn:

a. The .orig files were inadvertantly included in the patch, due to the late
hour
at the time I was making the patch.  I will submit a cleaned up patch with
these
removed.  Thanks for catching this!

b. I am not sure as to which file(s) you are referring to here?  I think the
case
statement is entirely appropriate for setting RPMCONFIGDIR in the toplevel
configure script, as it allows one to easily add other target arches whose
profiles pass in a --libdir= flag to the configure script.  If you are
referring
to the Makefile.in files, I will address my thoughts on this next.

c. Using ${libdir} in Makefile.in seems to be okay, as libdir is defined
elsewhere in the same file.  If --libdir=/usr/lib64 is explicitly passed
in (as is the case with amd64), the following line in Makefile.in:

libdir = @libdir@

will become:

libdir = /usr/lib64

However, for arches that do not pass in this flag, this line will use the
default setting:

libdir = ${exec_prefix}/lib

GNU make will then expand this expression to "/usr/lib" as it evaluates
${libdir}.

The breakage for arches other than amd64 was caused by the fact that
in the toplevel configure script, libdir is set to ${exec_prefix}/lib for
arches that do not pass in an explicit --libdir flag to configure.  On these
arches, the expression "`echo ${libdir}/rpm`" seems to expand to
"${exec_prefix}/lib/rpm" when defining RPMCONFIGDIR for some reason.

Having said all this, I do recognize that this patch is probably a little on
the ugly/hackish side, and I welcome any further modifications to make
it nicer.

I will submit a new patch that cleans up the excess .orig files.

Thanks again!

Created an attachment (id=58661) [details]
cleaned up version of previous patch submission to remove .orig files

More comments:
1) MARK64=64 is also defined in  {popt,file}/configure and so libpopt get's installed to /usr/lib6464 which isn't too usefull.

2) Guess this is the same as part b above but I'm not too keen on testing for x86_64 explicitly.

Another approach (and far simpler imo) is to use sed here as opposed to a patch, the following sed line should handle things for all multilib archs:

sed -i -e 's:MARK64=64:MARK64=:' \
    -e "s:/lib/rpm:/${get_libdir}/rpm:" \
    {,file/,popt/}configure scripts/Makefile.in || die

There are also a few hardcoded /lib/'s in the ebuild that need to be changed. I'll commit a fixed ebuild using this sed call as 4.2.1-r1 unless anyone has any objections?

I concur that using sed to eliminate the MARK64 setting in configure,
file/configure, and popt/configure is a better solution than the patch.
I am not opposed to that change.

However, the patch also addresses multilib issues in the file/ and
scripts/ subdirectories, which have hardcoded references to
${exec_prefix}/lib in the Makefile.in files in those.  This will cause
things to install into /usr/lib rather than /usr/lib64 on multilib arches.

Or am I missing something here?

that's what "s:/lib/rpm:/$(get_libdir)/rpm:" is for, i.e s:/lib/rpm:/lib64/rpm
on amd64.

Ah, of course.  I will try to drink my coffee first before responding next
time.  :-)

Sounds good, please make it so.

Con I just make a point:

I do not like the source rpm-4.2.1 comes from, it is a random Redhat inhouse development snapshot.

If you look at:
ftp://ftp.rpm.org/pub/rpm/dist/rpm-4.2.x/ you see it does not exist there.
( rpm-4.2-1.src.rpm is rpm-4.2 in portage )

I would like to remove rpm-4.2.1 and make everyone use rpm-4.2 as it is MUCH less buggy, and the official version rather than a undertested Redhat version

That is the reason why it is -x86 and rpm-4.2 is used, see Changelog

Could you amd64 ppl test rpm-4.2 and report? If works I'll zap 4.2.1 on amd64

Herbs: per cretin's suggestion, would you mind modifying the rpm-4.2 ebuild
with
your sed change?  I'll be glad to give it a workout on my systems, once it's in
the can.  Thanks!

Created an attachment (id=58687) [details]
rpm multilib fixes

Cretin: rpm-4.2 has the exact same problems with multilib as 4.2.1. But yes it
does work well here subject to these changes (which are the exact same changes
I was going to use in 4.2.1). I see no reason why these changes would have any
affect on anything other than a multilib system.

cparrott: Test away ;-) Note that after a bit of testing I decided that the
confdir /usr/lib/rpm should stay in /usr/lib since it contains arch independant
scripts (Which should be installed in /usr/lib according to FHS, just the
64-bit shared libraries go in /usr/lib64). Also this seems to hardcoded in a
couple of other places so is best left here all round.

Herbs: I tried the patch on both amd64 and ppc, and it worked fine for me.
I will add TESTED to the keywords for this bug, please feel free to commit the
ebuild change, keyworded for testing.

OK, committed 4.2-r1 with these changes, marked testing on all archs but stable
on amd64 (since current stable version fails to emerge). Also marked 4.2.1
-amd64 per  comment 19.

*** Bug 92892 has been marked as a duplicate of this bug. ***