[Qt5-feedback] Fwd: Re: Qt major versions

[Thiago Macieira]

On Wednesday, 8 de June de 2011 08:50:55 Till Oliver Knoll wrote:
> Ok, now I get it: And this style plugin, located somewhere on the system,
> also depends on Qt, and not being aware of the "bundled Qt" (inside the
> application folder) it also pulls *another* instance - the Qt libs located
> on the system - into the adress space.
> 
> And there you go, your application and all its Qt plugins it loaded are now
> linked to two Qt "instances" - maybe the same version, but most likely even
> different versions.

Right. If that happens, pray that the consequence is one of these two:

1) undefined symbol QObjectPrivate::checkWindowRole() [a symbol added by the 
KDE-Qt patch 0180, a new virtual in QObjectPrivate, which is not present in 
the standard Qt]

2) "Cannot mix incompatible Qt library (version 0x%x) with this library 
(version 0x%x)"

Those two actually stop the application dead in its tracks. It's clear there's 
a problem. So pray you have them, because the alternative is that it 
continues, starts to corrupt memory and do funky stuff that you can't detect.

> So I understand on Linux:
> 
> - You rely on the pre-installed Qt library, only shipping your own libs and
> executables or 
> - You set LD_LIBRARY_PATH accordingly, to make sure that
> also the "platform plugin" pulls in the proper (your) Qt lib instance

For the second, you have to ship *all* Qt libs, including the ones you don't 
directly need (like QtDBus).

> However, with regards to precedence of rpath (or runpath) over
> LD_LIBRARY_PATH or vice versa, it seems very unclear which one actually
> takes precedence, e.g.
[snip]

You may be getting confused because there are two ELF header entries. Without 
any entry, the search order is:

1) the paths specified in $LD_LIBRARY_PATH (if the program isn't setuid or 
setgid)

2) the paths specified in /etc/ld.so.config

3) the standard paths like /lib, /usr/lib and /usr/local/lib

If present, the older DT_RPATH entry takes precedence over everything and is 
searched before #1 above. The value of DT_RPATH in the main program is 
appended to the one found in the plugins, if any. So the presence of DT_RPATH 
in the program actually does tell the plugin to search your libs, unless the 
plugin itself has a DT_RPATH too. (My KDE build does)

The newer entry is DT_RUNPATH. It obsoletes the older entry. If DT_RUNPATH is 
present, the loader ignores DT_RPATH and pretends it doesn't exist. But unlike 
DT_RPATH, the newer entry does not take precedence over LD_LIBRARY_PATH. It 
inserts itself between #1 and #2 in the search order above.

My system is configured to create DT_RUNPATH dynamic tags. That way, I can run 
my Qt applications built with one version against another version. This is 
extremely useful for regression testing: I can just compile against the older 
version. Right now, I am running KDE with Qt 4.8, but it was compiled against 
Qt 4.7. If I see anything wrong, I can run with the older Qt and check if it 
is a regression. Similarly, when doing unit testing, I can just run the same 
test against two different Qt versions and verify that I did fix the problem.

> Sorry, this is really getting off-topic (and proper research with a small
> display device really a pain ;), but I'd be really curious what the current
> state (search order of LD_LIBRARY_PATH, rpath/runpath and system default
> paths) in recent Linux distributions is. I can't imagine that
> LD_LIBRARY_PATH would even take precedence even over system default paths
> such as /usr/lib!

It does.

> P.S. Sorry for the shitty HTML formatting

No problem. My KMail is configured to display the text portions of emails for 
qt-interest. That also means that emails sent HTML-only show the HTML source 
code. Since I have better things to do than to decipher HTML source code, I 
will never reply to HTML-only emails.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt.nokia.com/pipermail/qt5-feedback/attachments/20110608/3147c932/attachment.bin