Warren Falk

I’ve put the video card debacle on hold for now to compile KDE because it is convenient at this time to have my machine doing large compiles while I’m off doing other things. I have set up a script which runs the build, and then texts my cellphone when it is complete so that I don’t have to keep monitoring it. This is quite handy.

The first problem I run into is kde-base/superkaramba-3.5.2. I immediately tried 3.5.1 but it requires downgrading the kde-libs to 3.5.1 and I can’t do that because all the other packages depend on it. So I have to fix 3.5.2.

The failure message appeared to be that Python.h was missing in one of the compiles. However running make in the working directory didn’t reproduce that error. In fact, it succeeded fine. So I went and tried to run ebuild … install and there was the error, during the install phase, it is compiling. That led me down a wild goose chase. When I tried the whole thing over again step-by-step, I found that the compile appears to succeed, and portage things it succeeds, but it doesn’t. The configure script complains that it is missing Python.

Superkaramba can’t be compiled
because of missing Python libraries/headers.

Python is almost certainly installed, but let’s check:

# equery list python
[I--] [ ] dev-lang/python-2.4.2 (2.4)
[I--] [ ] dev-python/python-fchksum-1.7.1 (0)

Yep, it’s installed. So why does the configure script miss it? I’m looking at config.log and see that it finds Python 2.4 headers and libraries but apparently not the modules. I’m looking at this line:

configure:34568: result: header /usr/include/python2.4 library /usr/lib64 modules no

It is looking for the modules in the following locations:

configure: 34552: /usr/local/lib64/python2.4/copy.py
configure: 34552: /usr/lib64/python2.4/copy.py
configure: 34552: /usr/local/python2.4/copy.py
configure: 34552: /usr/lib64/python2.4/copy.py

Specifically it is looking for copy.py, and, of course, it isn’t in any of those locations, it is in /usr/lib/python2.4/copy.py. So I’m thinking that this has something to do with the fact that I’m on a 64bit system. Well, at least, that’s why it hasn’t been fixed yet.
It isn’t clear whether the configure script is looking in the wrong place, or the python installation isn’t quite right. My guess is to blame the configure script because it is searching the same location twice.

If I look at the configure script, I find that it in fact is hard coded to search the same location twice. Here’s the line:

python_libdirs=”$ac_python_dir/lib$kdelibsuff /usr/lib$kdelibsuff /usr/local /usr/lib$kdelibsuff $kde_extra_libs”

Notice that /usr/lib$kdelibsuff exists twice. Why would you want to search the same dir twice? I’m changed that to:

python_libdirs=”$ac_python_dir/lib$kdelibsuff /usr/lib$kdelibsuff /usr/local /usr/lib $kde_extra_libs”

…and reran configure. Look in config.log to find how portage is running configure. Mine was:

# ./configure –prefix=/usr
–host=x86_64-pc-linux-gnu
–mandir=/usr/share/man
–infodir=/usr/share/info
–datadir=/usr/share
–sysconfdir=/etc
–localstatedir=/var/lib
–with-x
–enable-mitshm
–without-xinerama
–with-qt-dir=/usr/qt/3
–enable-mt
–with-qt-libraries=/usr/qt/3/lib64
–disable-dependency-tracking
–disable-debug
–without-debug
–disable-final
–without-arts
–prefix=/usr/kde/3.5
–mandir=/usr/kde/3.5/share/man
–infodir=/usr/kde/3.5/share/info
–datadir=/usr/kde/3.5/share
–sysconfdir=/usr/kde/3.5/etc
–enable-libsuffix=64
–libdir=/usr/kde/3.5/lib64
–build=x86_64-pc-linux-gnu

This gives me:

Good – your configure finished. Start make now

And so I go back to portage to do run all the steps, but this time editing the file before compiling, and I find that the configure script is built from a file called acinclude.m4 where we want to make our change, and then I also see another file in the admin directory with the same line so I edit and change that one too just in case.

# cd /usr/portage/kde-base/superkaramba/
# ebuild superkaramba-3.5.2.ebuild clean
# ebuild superkaramba-3.5.2.ebuild unpack
# nano -w /var/tmp/portage/superkaramba-3.5.2/work/superkaramba-3.5.2/acinclude.m4
(made my change and saved)
# nano -w /var/tmp/portage/superkaramba-3.5.2/work/superkaramba-3.5.2/admin/acinclude.m4.in
(made my change and saved)
# ebuild superkaramba-3.5.2.ebuild compile

I remember, that the compile appeared to succeed, before, even though nothing was compiled, so this time, I am watching and I see the “Good – your configure finished…” message scroll by and it does, and portage is compiling stuff. I sigh with relief, cross my fingers and finish it off:

# ebuild superkaramba-3.5.2.ebuild install
# ebuild superkaramba-3.5.2.ebuild qmerge

All goes well.

[EDIT] … And I have no further problems compiling KDE 3.5.2

This entry was posted on Thursday, April 6th, 2006 at 4:25 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.