Summary: | kdeedu-3.2.0 cannot be emerge'd | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Christopher Knox <knoxc> |
Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | CC: | eradicator |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://forums.gentoo.org/viewtopic.php?t=132699 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Christopher Knox
2004-02-05 17:12:02 UTC
Did you run the /usr/sbin/python-updater script after updating your Python? yup - i did run python-updater and everything was fine I'm experiencing the same problem. dev-libs/boost-1.30.2 dev-lang/python-2.3.3 I'm going to try a newer boost. dev-libs/boost-1.31.0_alpha2-r1 fixed the problem. Perhaps boosting the boost DEPEND would be appropriate. ;) When I used boost 1.31.0_alpha2, kdeedu-3.2 did compile, but it looks like it doesn't make kig with python scripting. I got this message during the config: checking for main in -lboost_python... no configure: WARNING: Kig needs the Python and Boost.Python libraries and their headers installed for its Python scripting support. One of both was not found, and Python scripting will be disabled. I don't know enough about kig to actually tests and see if the scripting is disabled. It looks like boost 1.31.0_alpha2 provides these libraries: /usr/lib/libboost_python-gcc-mt-d-1_31.so /usr/lib/libboost_python-gcc-d-1_31.so /usr/lib/libboost_python-gcc-mt-1_31.so /usr/lib/libboost_python-gcc-1_31.so and corresponding versioned .so files and .a files, but not a plain libboost_python.so or libboost_python.a. Note that boost 1.31.0_alpha2 is marked ~x86, so having kdeedu-3.2 depend on it would probably not work. In fact, kdeedu-3.2 doesn't seem to have any reference to boost at all, and I assume it would emerge fine without boost (especially since otherwise I doubt kededu-3.2 would have even been marked stable). So the problem may be in kdeedu's config, which seems to find boost and but not check that it's a recent enough version to work with the version of python it found. (If that's even possible.) For gentoo, perhaps the ebuild could be modified to add the --disable-kig-python-scripting flag to config if there's a version of boost installed that's too old, so as to at least prevent the emerge failure? (And perhaps also to tell it which library to use to actually enable kig's python scripting if the boost is newer.) BTW, note that attempting to emerge boost 1.30.2 with python-2.3.3 appears to fail with a similar error. is this still an issue in any recent (3.2.3, 3.3) kde version? Yep, seems to be a problem with kdeedu-3.3... I can't emerge it at all, spews out a load of stuff that I will need to read through more closely tomorrow, and then dies with: make[3]: Leaving directory `/var/tmp/portage/kdeedu-3.3.0/work/kdeedu-3.3.0/kig/scripting' make[3]: Entering directory `/var/tmp/portage/kdeedu-3.3.0/work/kdeedu-3.3.0/kig' touch dummy.cpp /bin/sh ../libtool --silent --mode=compile --tag=CXX g++ -DHAVE_CONFIG_H -I. -I. -I.. -DQT_THREAD_SUPPORT -D_REENTRANT -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -DNDEBUG -DNO_DEBUG -O2 -O3 -march=pentium4 -fprefetch-loop-arrays -funroll-loops -fomit-frame-pointer -pipe -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -c -o dummy.lo dummy.cpp /bin/sh ../libtool --silent --mode=link --tag=CXX g++ -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -DNDEBUG -DNO_DEBUG -O2 -O3 -march=pentium4 -fprefetch-loop-arrays -funroll-loops -fomit-frame-pointer -pipe -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -o libkigpart.la -rpath /usr/kde/3.3/lib/kde3 -module -avoid-version -module -no-undefined -Wl,--no-undefined -Wl,--allow-shlib-undefined -R /usr/kde/3.3/lib -R /usr/qt/3/lib -R /usr/X11R6/lib -L/usr/X11R6/lib -L/usr/qt/3/lib -L/usr/kde/3.3/lib dummy.lo -lkparts misc/libmisc.la objects/libobjects.la filters/libfilters.la modes/libmodes.la scripting/libscripting.la kig/libkigparttemp.la /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lboost_python collect2: ld returned 1 exit status distcc[14037] ERROR: compile (null) on localhost failed make[3]: *** [libkigpart.la] Error 1 make[3]: Leaving directory `/var/tmp/portage/kdeedu-3.3.0/work/kdeedu-3.3.0/kig' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/kdeedu-3.3.0/work/kdeedu-3.3.0/kig' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/kdeedu-3.3.0/work/kdeedu-3.3.0' make: *** [all] Error 2 !!! ERROR: kde-base/kdeedu-3.3.0 failed. !!! Function kde_src_compile, Line 135, Exitcode 2 !!! died running emake, kde_src_compile:make I'm wondering slightly whether this is anything to do with having compiled boost with the intel compiler...? for kde-3.4, I've disabled kig python scripting support with this comment in the ebuild: # the scripting support in kig is strongly dependent on the version # of dev-libs/boost and of python installed, and often fails to compile. myconf="${myconf} --disable-kig-python-scripting" I can't compile kig from kde-3.4 even with boost 1.31.0 (and I have libboost_python.so). See also http://bugs.kde.org/show_bug.cgi?id=79354 If anyone is able to track down this problem more accurately, please report it so we can add python scripting support back in. I'm closing this as CANTFIX in the meanwhile. |