A number of applications that fail with the following error: checking for Qt... configure: error: Qt (>= Qt 3.0.3) (library qt-mt) not found. Please check your installation! simply need a symbolic link from lib64 to lib in /usr/qt/3/ similarly for kde. ebuilds that fail with the following error: in the prefix, you've chosen, are no KDE libraries installed. This will fail. So, check this please and use another prefix! simply need a symbolic link from lib64 to lib in /usr/kde/(version number) would it be possible for the qt and kdelibs ebuilds to conditionally install these symbolic links for amd64? Reproducible: Always Steps to Reproduce: 1. emerge /usr/portage/app-crypt/kgpg/kgpg-1.0.0.ebuild and watch it fail on qt 2. make qt symlink and see it get further 3. make kde symlink and see the same 4. repeat for a few of the kde sound applications, like rosegarden Actual Results: errors Expected Results: well, to get technical i expected errors as these are all masked ebuilds at the moment, but they SHOULD merge. well, some of them anyway, Portage 2.0.50-r1 (default-amd64-2004.0, gcc-3.3.3, glibc-2.3.3_pre20040207-r0, 2.6.5-rc2-lv1) ================================================================= System uname: 2.6.5-rc2-lv1 x86_64 4 Gentoo Base System version 1.4.3.13p1 Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.2 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-O3 -fomit-frame-pointer -ftracer -pipe" CHOST="x86_64-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -fomit-frame-pointer -ftracer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs buildpkg ccache sandbox" GENTOO_MIRRORS="ftp://mirror.iawnet.sandia.gov/pub/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/local/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl acpi alsa amd64 apm arts avi berkdb bidi bonobo canna cap caps cddb cdr cjk crypt cscope cups dga directfb divx dvd dvdr encode escreen etwin evo expat faad fam fbcon ffmpeg flash foomaticdb freetype gdbm ggi gif gnome gpm gstreamer gtk gtk2 gtkhtml idea imlib imlib2 jack java javascript jpeg kde kerberos ladcca libg++ libgda libwww mad mikmod motif mozilla moznocompose moznoirc moznomail mozp3p mozsvg mpeg mpeg4 ncurses nls nogcj nvidia objc ocaml offensive oggvorbis openal opengl oss pam pcap pdflib perl pic png pthreads python qt quicktime readline ruby samba sdk sdl serial skey slang slp snmp socks5 sox spell ssl svg tcltk tcpd tiff truetype usb utf8 v4l wxwin wxwindows xchattext xine xinerama xml xml2 xmms xv xvid zlib zvbi"
I forgot to mention that kgpg works perfectly on amd64 with these links made, and should have ~amd64 added to it's keywords, possibly with a check for these links and a descriptive error?
Gentoo's policy is to NOT have lib64 directories, so if an ebuild is trying to look for it then it's a bug with that particular build.
if it's gentoo's policy to not have lib64 directories, then why not remove lib64 from baselayout? lv@ayanami lv $ ls -l /lib64 lrwxrwxrwx 1 root root 3 Mar 23 22:27 /lib64 -> lib lv@ayanami lv $ qpkg -f /lib64 sys-apps/baselayout * sys-apps/procps * why perform a useless hack on each and every single ebuild when all it takes is two symlinks to fix the whole problem?
lv@ayanami lv $ ls -l /usr/lib64 lrwxrwxrwx 1 root root 3 Mar 23 22:27 /usr/lib64 -> lib lv@ayanami lv $ qpkg -f /lib64 sys-apps/baselayout * sys-apps/procps * or what about /usr/lib64? is this also something that needs to be removed from baselayout in an effort to be unnecessarily non-compliant?
i dunno - i think it's a bit smarter to have the lib64 directories myself, but this is just what i'm told (by the 64 bit folks). Perhaps a dialogue with them would be helpful.
Can a 64 bit person (Aron?) provide some insight here.
I am not sure who said that lib64 directories are bad, but I see them as being perfectly valid.
Well, as a new Gentoo/AMD64 dev I concur (with my previous statement and avenj) that lib64 symlinks are perfectly valid here. Do I have the permission of the kde herd to add conditional symlinks for amd64?
I was told by agriffis (in another bug report I believe) that the 64 extension isn't used in Gentoo. Perhaps that's been changed since then, or perhaps I misunderstood. Dunno what the official policy is here - you can pass an --enable-suffix to the configure script to tell it where to look for 64 bit libraries though...
the problem is that the symlink potentially fixes all ebuilds that depend on qt and kde, while configure options would have to be added to each of these ebuilds individually. additionally, many wont even work with configure options due to hardcoded assumptions, and would require further patching.
agriffis - input appreciated :)
Originally, the plan was to _not_ have any kind of multilib support. This has since changed and we do implement multlib, albeit in a pretty minor way. In any case, the point is that it's perfectly acceptable policy-wise to use lib64 8)
Regarding alpha and ia64, see bug 46546 comment 9 where I've commented on this issue previously. In short, if these applications or libraries are looking for "lib64" on alpha or ia64, the app/lib needs to be fixed to use pure "lib" and pushed upstream. Using a lib64 symlink is a dirty hack and should be avoided if at all possible for alpha/ia64 (I'm not speaking for the other arches)
Thanks. From my perspective, the 64 bit folks are welcome to do whatever it is they need to do to make this stuff work, with the presumption that they'll take on the responsibility for any breakage :)
fixes are in cvs. thankyou very much, and try not to hurt me too bad in case something does accidentally break. ;)
