Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 36546 - Patch to allow amd64 to build the kdevelop-2.1.5.
Summary: Patch to allow amd64 to build the kdevelop-2.1.5.
Status: RESOLVED TEST-REQUEST
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] KDE (show other bugs)
Hardware: AMD64 Linux
: High enhancement
Assignee: Gentoo KDE team
URL:
Whiteboard:
Keywords:
: 37200 (view as bug list)
Depends on: 36545
Blocks:
  Show dependency tree
 
Reported: 2003-12-26 12:22 UTC by Mikael Rosbacke
Modified: 2004-01-15 01:13 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
File with patch to modify the ebuild file. (patch.txt,707 bytes, patch)
2003-12-29 10:38 UTC, Mikael Rosbacke
Details | Diff
File to place in 'files' (amd64-configure-hack.diff,915 bytes, patch)
2003-12-29 10:41 UTC, Mikael Rosbacke
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mikael Rosbacke 2003-12-26 12:22:23 UTC
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"
Comment 1 Mikael Rosbacke 2003-12-29 10:38:43 UTC
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
Comment 2 Mikael Rosbacke 2003-12-29 10:41:02 UTC
Created attachment 22806 [details, diff]
File to place in 'files'

This file should be placed in the kdevelop/files.
Comment 3 Jörg Spanke 2004-01-05 11:28:09 UTC
*** Bug 37200 has been marked as a duplicate of this bug. ***
Comment 4 Caleb Tennis (RETIRED) gentoo-dev 2004-01-06 11:17:38 UTC
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).
Comment 5 Jörg Spanke 2004-01-06 11:32:38 UTC
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.
Comment 6 Mikael Rosbacke 2004-01-06 14:08:38 UTC
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.
Comment 7 Jörg Spanke 2004-01-06 23:49:14 UTC
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?  
Comment 8 Caleb Tennis (RETIRED) gentoo-dev 2004-01-07 05:01:15 UTC
Hopefully one of these cc'ed 64 bit folks can help us out with this and the few other bugs that want /lib64 directories.
Comment 9 Aron Griffis (RETIRED) gentoo-dev 2004-01-07 06:06:35 UTC
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.
Comment 10 Mikael Rosbacke 2004-01-14 12:18:35 UTC
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.
Comment 11 Mikael Rosbacke 2004-01-14 13:28:23 UTC
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.
Comment 12 Aron Griffis (RETIRED) gentoo-dev 2004-01-14 19:19:04 UTC
> 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
}
Comment 13 Mikael Rosbacke 2004-01-15 01:13:39 UTC
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
}