Currently kdevelop-2.1.5 does not build on the amd64 platform. Two reasons: 1. There is an error in the source-code. (See bug #36545) 2. The configure script can not find qt and kde libraries due to the lib64 extension. The configure scripts detects the /lib64 directory and assumes _all_ lib-directories should be named lib64. This is currently not the case for qt and kde and configure fails to find the right directory. My patch add a new search path to the configure script to allow it to find the qt and kde libraries with the old names. Apply this patch to kdevelop-2.1.5.ebuild: --- /usr/portage/dev-util/kdevelop/kdevelop-2.1.5.ebuild 2003-03-13 11:24 :51.000000000 +0100 +++ kdevelop-2.1.5.ebuild 2003-12-26 21:05:38.936647544 +0100 @@ -15,7 +15,7 @@ mirror://gentoo/$PN-2.1.3-qt-templates.tar.gz" LICENSE="GPL-2" -KEYWORDS="x86 ppc" +KEYWORDS="x86 ppc amd64" newdepend ">=kde-base/kdebase-3 >=dev-util/kdoc-2.0_alpha24 @@ -45,6 +45,15 @@ mv q*.tar.gz ${S}/kdevelop/templates/ cd ${S} epatch ${FILESDIR}/${P}-gentoo.diff + + #This adds the extra search paths needed to find kde & qt dir + #it should be removed once kde and qt start using lib64 as + #library names (MR) + if [ "${ARCH}" = "amd64" ] + then + epatch ${FILESDIR}/amd64-configure-hack.diff + fi + #end amd64 fix } src_compile() { Also, create a new file 'files/amd64-configure-hack.diff' containing this patch: --- configure.orig 2003-01-20 02:26:01.000000000 +0100 +++ configure 2003-12-26 20:23:49.353468994 +0100 @@ -21550,6 +21550,12 @@ ac_qt_libraries="$withval" kde_qt_libs_given=yes +# Ugly workaround +else + ac_qt_libraries="$QTDIR/lib" + kde_qt_libs_given=yes +# End ugly. + fi; if test "${ac_cv_have_qt+set}" = set; then @@ -22395,6 +22401,7 @@ kde_libdirs="/usr/lib/kde/lib${kdelibsuff} /usr/local/kde/lib${kdelibsuff} /usr/kde/lib${kdelibsuff} /usr/lib${kdelibsuff}/kde /usr/lib${kdelibsuff}/kde3 /usr/lib${kdelibsuff} /usr/X11R6/lib${kdelibsuff} /usr/local/lib${kdelibsuff} /opt/kde3/lib${kdelibsuff} /opt/kde/lib${kdelibsuff} /usr/X11R6/kde/lib${kdelibsuff}" test -n "$KDEDIR" && kde_libdirs="$KDEDIR/lib${kdelibsuff} $KDEDIR $kde_libdirs" kde_libdirs="$ac_kde_libraries $libdir $kde_libdirs" +kde_libdirs="$kde_libdirs ${KDEDIR}/lib" kde_libdir=NO for i in $kde_libdirs; This should allow amd64 to build kdevelop. --- Mikael R Reproducible: Always Steps to Reproduce: 1. 2. 3. Portage 2.0.49-r15 (default-amd64-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.6.0-gentoo) ================================================================= System uname: 2.6.0-gentoo x86_64 4 Gentoo Base System version 1.4.3.12 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-O3" CHOST="x86_64-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="" DISTDIR="/usr/portage/distfiles" FEATURES="sandbox ccache autoaddcvs" GENTOO_MIRRORS="ftp://gentoo.linux.no/pub/gentoo/ ftp://trumpetti.atm.tut.fi/gentoo/ http://ds.thn.htu.se/linux/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 oss 3dnow apm avi crypt encode foomaticdb gif gpm gtk2 jpeg gnome libg++ mikmod mmx mpeg ncurses nls pdflib png quicktime sdl slang spell sse truetype xml2 xmms xv zlib alsa gdbm berkdb readline arts tetex X tcpd pam libwww ssl perl python esd imlib oggvorbis gtk qt kde motif opengl acpi cdr cups dvd dvdr emacs freetype multilib ppds radeon samba usb --cups --java --qt"
Created attachment 22805 [details, diff] File with patch to modify the ebuild file. The patch for the ebuild supplied as an attachment. To apply patch: cd /usr/portage/dev-util/kdevelop cat patch.txt | patch -p0
Created attachment 22806 [details, diff] File to place in 'files' This file should be placed in the kdevelop/files.
*** Bug 37200 has been marked as a duplicate of this bug. ***
i'm looking into this, i promise. however, it's not correct to patch 'configure' as it is a script that gets generated and can possibly be overwritten. it's better to patch configure.in.in, or pass an argument to configure (like --enable-libsuffix).
I tried to disable the libsuffix with --disable-libsuffix but I didn't do the trick (or I made some mistake). I guess it would be even better to add a /lib64 to all /lib directories.
Ok. I can give my line of thinking before choosing this type of approach. I'm not really sure of how lib, lib32 and lib64 is supposed to be used, but I guess lib64 is for 64-bit, lib32 for 32 bit and lib is only used when you don't care if the library is 32 or 64 bit. Further, I guess that in the long run, the amd64 system will use the lib32 and lib64 for the two types of libraries (that is in Utopia at least.) so the right thing would be to put qt and kde in lib64 given these assumptions. I'm running Xfree 4.3.902 and it installs in lib64 so i guess this is the way to go. So a fix should probably gracefully try to search lib64 before it tries the old lib path. I think the best thing would be to ask the kdevelop team to fix this so it can build cleanly when the next version is released. But until then, we need to do something. I tried to fix it with arguments to configure and it works for qt but not for kde. Rather than having two different ways for qt and kde, I choose to try to do them both the same way. Changing configure.in.in requires the ebuild to rerun autoconf. I wasn't prepared to implement that so I changed configure. Any idea's, comments, suggestion how this should be handled are welcome, it will surely come up again in other applications.
I think there are a few things to consider: http://dev.gentoo.org/~brad_mssw/amd64-tech-notes.html describes in: <cite> The 32bit Environment The emulation libraries will create the /emul/linux/x86 directory and install most of the appropriate libraries you will need to run pre-compiled 32bit applications. It will also create 2 symlinks, /lib32, and /usr/lib32 which point back to the proper /emul directories. It will also create a symlink in /lib to ld-linux.so.2 from /emul/linux/x86/lib/ld-linux.so.2, as the 64bit variant is known as ld-linux-x86-64.so.2. </cite> I guess that is the reason for /lib32 etc. Another advice comes from http://www.x86-64.org/lists/discuss/msg02621.html: <cite> Libraries are in /lib64 64bit libraries are in */lib64 instead of */lib. Makefiles that install libraries must be changed for this. Also the common -L/usr/X11R6/lib compile flag or a similar flag for the Qt library must be changed to reference */lib64. </cite> Only question is, if this is handled via symlink, because the "old" */lib has got no special meaning and all 64 bit libraries can be stored there or if every 64 bit library should be stored in */lib64. I am just wondering that this hasn't been discussed before, because on the long run there will be only 64 bit libraries on a 64 bit system. Only if an 32 bit emulation is required there should be a /lib32. Where are the system architects who decides about such naming conventions, e.g. Linux Standard Base (LSB)? How is this handled on IA64?
Hopefully one of these cc'ed 64 bit folks can help us out with this and the few other bugs that want /lib64 directories.
Both ia64 and alpha use simple "lib" for 64-bit libraries. "lib64" should never be used for anything on these architectures. In the case of alpha, 32-bit binaries are never supported so the decision was made early in the Linux/Alpha port to refrain from lib64. I'm referring to the original Linux/Alpha port, not the Gentoo port, though we continue to follow the established standard. In the case of ia64, 32-bit ia32 binaries are supported by the architecture. Nonetheless, Mosberger made the decision when doing the Linux/IA-64 kernel port to use "lib" for 64-bit libraries and "lib32" (or something similar) for 32-bit libraries since it's highly discouraged to use the chip's ia32 mode. The reason I say "something similar" is becauase it actually can be decided at the distribution level. For Gentoo we haven't decided what to use yet for 32-bit libraries on ia64 because we haven't attempted to support ia32 binaries yet.
After some mailing on the amd64 list it seems clear that 'lib' is the correct name of the directory. I have managed to get kdevelop to compile by using the option "--enable-libsuffix=''" to configure. This means we can scrap the patches given before. However, I have not managed to give this argument to 'kde_src_compile' in the ebuild file.
I think I finally nailed this one. replace src_compile() with the following. src_compile() { export myconf="--enable-libsuffix=" kde_src_compile myconf kde_src_compile configure kde_src_compile make cd ${WORKDIR}/c_cpp_reference-2.0.2_for_KDE_3.0 econf --with-qt-dir=/usr/qt/3 emake } Note that I hav'nt tested this with any other platform than amd64. But it works for me.
> export myconf="--enable-libsuffix=" kde_src_compile myconf I don't think this statement is doing what you think. This instructs bash to put three shell variables into the environment of subprocesses: myconf (with the value "--enable-libsuffix=", kde_src_compile, and myconf.. again). Considering that kde_src_compile is a function that runs in the same shell session, there's really no reason to export myconf at all, in fact it should be a local function variable so that it doesn't survive past src_compile. You should just do: src_compile() { local myconf="--enable-libsuffix=" kde_src_compile myconf kde_src_compile configure kde_src_compile make cd ${WORKDIR}/c_cpp_reference-2.0.2_for_KDE_3.0 econf --with-qt-dir=/usr/qt/3 emake }
True. It work fine. I thought 'kde_src_compile' was running as a separate sub-process, therefore the export. Using local seems like a cleaner solution. A new suggestion: src_compile() { local myconf="--enable-libsuffix=" kde_src_compile all cd ${WORKDIR}/c_cpp_reference-2.0.2_for_KDE_3.0 econf --with-qt-dir=/usr/qt/3 emake }
