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. 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. * 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? * 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. Anyway, in the meantime, this can be fixed in the kdelibs package by adding $(LIB_KDECORE) explicitly to meinproc_LDADD, which it's appropriate to list anyway since meinproc directly uses kdecore functions. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]