[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Help: "Cannot mix incompatible Qt libraries"
From:       "Guillaume Pothier" <gpothier () gmail ! com>
Date:       2008-08-27 16:42:10
Message-ID: 8caa8ded0808270942mb3393c1te76ad8845337aaa1 () mail ! gmail ! com
[Download RAW message or body]

Thanks for the explanation Thiago!
Actually, it seems the problem is not fixed after all. I reverted my
whole kdesupport tree to HEAD (removing the RPATH cmake options I
copied from akonadi to soprano, phonon and co), and the libs are wrong
again.

There are a few things I don't understand:
- Yesterday, after adding the correct RPATH in kdesupport, no lib
tried to link to my system's Qt anymore.  However some apps (eg
dolphin) did, although I did also rebuild them (with kdesvn-build
--reconfigure).
- Today, rebuilding kdebase made those apps work again. Then reverting
kdesupport made the libs wrong again, but the apps still work, even
after rebuilding.
- And most importantly: why did everything work without problems until
a few days ago, and now doesn't? Is everything working for everybody
except Michael Jansen and I?

Regards,
g

On Wed, Aug 27, 2008 at 12:08 PM, Thiago Macieira <thiago@kde.org> wrote:
> 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
>
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
>
>
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]