Bug 4351 – gcc-3.1-r7 / libtool-1.4.1-r8 / kde libtool problems...

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Daniel Robbins (RETIRED) 2002-06-30 11:08:45 UTC]

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 .

[Comment 1 Martin Schlemmer (RETIRED) 2002-06-30 11:19:55 UTC]

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.

[Comment 2 Daniel Robbins (RETIRED) 2002-06-30 18:15:31 UTC]

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?

[Comment 3 Daniel Robbins (RETIRED) 2002-06-30 18:20:10 UTC]

I also think it would be very wise to see how other distributions like Mandrake
and Red Hat handle these issues.

[Comment 4 Daniel Robbins (RETIRED) 2002-06-30 18:22:44 UTC]

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)

[Comment 5 Brandon Low (RETIRED) 2002-06-30 20:10:48 UTC]

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.

[Comment 6 Martin Schlemmer (RETIRED) 2002-07-01 12:26:47 UTC]

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.

[Comment 7 Dan Armak (RETIRED) 2002-07-03 15:51:46 UTC]

*** Bug 4493 has been marked as a duplicate of this bug. ***

[Comment 8 Brandon Low (RETIRED) 2002-07-08 11:37:35 UTC]

looks like azarah has dealt with this in gcc-3.1-r8 which is masked for testing
still.