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 attachment 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 attachment 55249 [details, diff] 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 attachment 58643 [details, diff] 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 attachment 58661 [details, diff] 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 attachment 58687 [details, diff] 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. ***
