On Quarta 27 Agosto 2008 16:57:10 Guillaume Pothier wrote: > Well, it seems this problem got fixed now. I'd like to understand what > happenned anyway, anybody knows which commit did the fix? I don't know what commit fixed it, but I can tell you what the problem is: When you link to a library, you pass arguments like: -L$QTDIR/lib -lQtCore. The linker will then do its magic and it'll write a binary for you. In the header of that binary, it lists what libraries it needs. That's the NEEDED entries you saw on the objdump -p output (-p stands for "platform headers" or "private headers"). It matches all of the libraries that you pass with -l. However, the -L entries are not saved anywhere. There's another entry you can have called RPATH or RUNPATH that sets the paths where to find those libraries, in order of preference. But you need an extra linker option passed in order to set those. The kdesupport libraries did not or still do not have those extra options. Also note that the ELF loading process requires a depth-first loading. So when dolphin links to libkdecore, libkdecore has to be successfully loaded before any dependencies of dolphin appear. And since libkdecore links to soprano or phonon, those have to be loaded before libkdecore loads. And what happened? Soprano, strigi and phonon could not be loaded because of the missing entries. Or, in your original case, since the RPATH/RUNPATH were not present, the loader found the system Qt libraries and loaded those. But when it came to loading the dependencies of kdecore or dolphin, it loaded QtSvg from a different Qt build. And that's not allowed. Hence $subject. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Attachment:
signature.asc
Description: This is a digitally signed message part.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<