When merging kdelibs-3.0.1.20020604.ebuild: make[3]: Leaving directory `/tmp/portage/kdelibs-3.0.1.20020604/work/kdelibs-3.0.1/kio/kfile' Making all in . make[3]: Entering directory `/tmp/portage/kdelibs-3.0.1.20020604/work/kdelibs-3.0.1/kio' i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./.. -I../dcop -I../libltdl -I../kdecore -I../kdeui -I../kio -I../kio/kio -I../kio/kfile -I/usr/qt/3/include -I/usr/X11R6/include -I/usr/kde/3/include -D_LARGEFILE64_SOURCE -DQT_THREAD_SUPPORT -D_REENTRANT -DNDEBUG -DNO_DEBUG -O2 -march=athlon-tbird -O3 -pipe -fno-exceptions -fno-check-new -DQT_NO_TRANSLATION -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_COMPAT -c libkio_la_closure.cpp -fPIC -DPIC -o .libs/libkio_la_closure.o /bin/sh ../libtool --mode=link --tag=CXX i686-pc-linux-gnu-g++ -DNDEBUG -DNO_DEBUG -O2 -march=athlon-tbird -O3 -pipe -fno-exceptions -fno-check-new -DQT_NO_TRANSLATION -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_COMPAT -o libkio.la.closure libkio_la_closure.lo -version-info 4:0 -no-undefined -L/usr/X11R6/lib -L/usr/qt/3/lib -L/usr/kde/3/lib dummy.lo kssl/libkssl.la kio/libkiocore.la kio/libksycoca.la bookmarks/libkbookmarks.la kfile/libkfile.la ../kdeui/libkdeui.la ../kdesu/libkdesu.la -lz -lfam libtool: link: cannot find the library `/usr/lib/gcc-lib/i686-pc-linux-gnu/3.1/libstdc++.la' make[3]: *** [libkio.la.closure] Error 1 make[3]: Leaving directory `/tmp/portage/kdelibs-3.0.1.20020604/work/kdelibs-3.0.1/kio' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/portage/kdelibs-3.0.1.20020604/work/kdelibs-3.0.1/kio' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/portage/kdelibs-3.0.1.20020604/work/kdelibs-3.0.1' make: *** [all-recursive-am] Error 2 !!! ERROR: The ebuild did not complete successfully. !!! Function kde_src_compile, Line -3922, Exitcode 2 !!! died running emake, kde_src_compile:make !!! emerge aborting on /usr/portage/kde-base/kdelibs/kdelibs-3.0.1.20020604.ebuild .
Hmms, I was scared that changing $libdir will have some impact. I guess we can fix it one of three ways: 1) leave the libdir sed as it is now, but install the .la files in /usr/lib/ AND /usr/lib/gcc-lib/i686-pc-linux-gnu/3.1/. 2) Move the .la's to /usr/lib/gcc-lib/i686-pc-linux-gnu/3.1/ and leave the libdir sed as it is now 3) Dont modify $libdir, but still move the .la's to /usr/lib/gcc-lib/i686-pc-linux-gnu/3.1/ as with the dual installation which seem to work fine with all problems that was experienced with the single install. Anyhow, whatever should be tested well I guess before it is changed again.
I am certainly not an expert on these libtool issues, but would it be possible to have libtool always check /usr/lib as a fallback if the .la file doesn't exist in the specified location?
I also think it would be very wise to see how other distributions like Mandrake and Red Hat handle these issues.
libtool: link: warning: `/usr/lib/libstdc++.la' seems to be moved libtool: link: warning: `/usr/lib/libstdc++.la' seems to be moved When I copied the .la files to the /usr/lib/gcc-lib/i686-pc-linux-gnu/3.1/, I got those warnings but everything seemed to work. It may indicate that the solution I chose is not optimal (we don't want warnings like that)
the -r7 ebuild currently in rsync does what you did to fix it (as I mentioned in #gentoo-dev) I'm going research as to how other distros handle this issue, and if I find a better fix I'll -r8 it. I'm leaving this bug open so that users will see it just in case they got the bad -r7, and to remind me to find a better fix.
Well, -r6 is pretty much what Mandrake does, and I guess then Redhat as well. This setup allows multiple installations, and did work well with 3.0.4 and gcc-3.1 except for gimp-print. I think that maybe we should check how they handle gimp-print, as it could be something that is broken in there, rather than our gcc-3.1-r6 ebuild.
*** Bug 4493 has been marked as a duplicate of this bug. ***
looks like azarah has dealt with this in gcc-3.1-r8 which is masked for testing still.
