Bug#355099: Bug #355099: kdelibs FTBFS
On Fri, Mar 10, 2006 at 02:02:04PM +0100, Daniel Schepler wrote:
> After some investigation of the failure of kdelibs to build, I found it
> appears to be a bug in either libtool, ld, or the dynamic linker, so I'm
> CC'ing the maintainers of those packages. The problem is that lt-meinproc is
> getting linked with a NEEDED entry pointing to libkdecore.so because it
> directly uses symbols from that library, which is indirectly brought in by
> the -lkio argument, but the RPATH on the resulting binary only includes the
> directory containing libkio.so.
I think the commands you're talking about being issued here are:
/bin/sh ../libtool --tag=CXX --mode=link g++ -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -g -Wall -O2 -DDEBIAN_VERSION=4:3.5.1-3 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -L/usr/lib -L/usr/share/qt3/lib -L/usr/X11R6/lib -o meinproc meinproc.o xslt_pure.o libkbzipfilter_dummy.la -L/usr/lib -lxslt -lxml2 -lz -lm -L/usr/lib -lxml2 -lz -lm ../kio/libkio.la -lbz2
g++ -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align-Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -g -Wall -O2 -DDEBIAN_VERSION=4:3.5.1-3 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -o .libs/meinproc meinproc.o xslt_pure.o -L/usr/lib -L/usr/share/qt3/lib -L/usr/X11R6/lib ./.libs/libkbzipfilter_dummy.a /usr/lib/libxslt.so /usr/lib/libxml2.so -lz -lm ../kio/.libs/libkio.so -lbz2
So basicly, there isn't a -lkdecore, while there should
have been one. I consider this to be a bug in the
package. The linker however adds in case it can detect
it, as you seem to be aware of. See
http://sourceware.org/ml/binutils/2005-09/msg00200.html
for those who don't.
As you say later in the mail adding kdecore to the link
line solves this, and I think this should be done in any
case.
Looking at the result of an ldd on lt-meinproc I see:
[...]
libkdecore.so.4 => not found
[...]
libkdecore.so.4 => /usr/src/kdelibs-3.5.1/obj-x86_64-linux-gnu/kdecore/.libs/libkdecore.so.4 (0x00002aaaae6dc000)
Where the first one comes from the executable itself,
which doesn't have an rpath, and the second one comes from
libkwalletclient.so.1 (thru libkio.so.4)
> Then the dynamic linker can't find where
> libkdecore.so is, despite the fact that libkio.so's RPATH includes the
> directories containing its dependencies, and one of those libraries has the
> RPATH needed for libkdecore.so.
> So I can see a few different ways to fix this:
>
> * Make libtool include all indirect rpath's directly on the link command line.
> But I find this ugly, and in fact a step backwards from recent improvements,
> and it really doesn't solve the general problem either.
I've been pondering wether libtool should always add
rpaths to libraries/binaries as long as they're not
installed, but that has a few problems. One of them is,
you'll always need to relink when you want to install it
to remove the rpath's that you don't need. An other is
that it's probably not very portable.
One of the reasons I thought about this is #320698.
> * Make the dynamic loader able to find libraries within rpath's from already
> loaded libraries. But this doesn't totally solve the case outside libtool --
> what if that other library then gets relinked in such a way that it doesn't
> indirectly include that rpath anymore?
I think that 2 libraries with the same soname should be
considered the same file. However, I think the problem is
that in the executable (lt-meinproc) there is no rpath, so
it can't find it at that time. Then later some other
libraries get loaded, and one of them needs the same
library again, but this time has an rpath. I think it's
reasonable to expect it to fail. I think if it tried to
load them in a different order, it would have worked, but
I don't think it should.
> * Make ld add the required directory to RPATH when it automatically adds a
> NEEDED entry due to direct usage of symbols from the library involved.
> Somewhat ugly, though.
I already find it ugly that it adds the NEEDED by
itself, please don't make it automaticly add RPATH's too.
But if it wouldn't have added the NEEDED in the first
place, you would have known that you needed to link
to kdecore sooner, and wouldn't have this problem.
I'm still for removing this feature from the linker.
Kurt
Reply to: