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

[Till Oliver Knoll]

Am 07.06.2011 um 09:04 schrieb Thiago Macieira <thiago at kde.org>:
> 
> Qt wants to use this platform plugin. The code to load it is inside QtGui. So 
> Qt might load it and the style plugin regardless of what you wanted. 

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.

But in any case this calls for trouble. It's like linking to a binary on Windows which itself links to a different C/C++ runtime library due to different linker settings or compiler versions: these versions access then different global data, conflicting each other.


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


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.

  http://www.mail-archive.com/libtool@gnu.org/msg09786.html

To make matters worse, it seems to be even distribution-dependent which one takes precedence! But to be fair, this post is from 2007, so things might have changed.

Then again, this site claims that:

"The search paths for libraries come from three sources: the environment variable LD_LIBRARY_PATH (if set), any rpath encoded in the binary (more on this later), and the system default search paths. They're searched in this order, and the first matching library found is used."

http://www.eyrie.org/~eagle/notes/rpath.html

Now this really surprises me, since that would mean it would be very easy to inject malicious libraries simply by tampering with LD_LIBRARY_PATH!

The site even claims that "LD_LIBRARY_PATH is broken and should not be used". Exactly for the reasons that it would override rpath and even default (!) library paths - security by recommendation, so to speak ;)

On the other hand:

"An RPATH is similar to a better known mechanism called LD_LIBRARY_PATH, but the RPATH is hard-coded into the executable (not the code, but the executable's header), unlike the LD_LIBRARY_PATH which is set by users. RPATH also takes precedence over LD_LIBRARY_PATH."

http://www.globus.org/toolkit/rpaths.html

So they claim the opposite again (in 2008).


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!

Any security expert here? :)

Cheers, Oliver

P.S. Sorry for the shitty HTML formatting

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt.nokia.com/pipermail/qt5-feedback/attachments/20110608/3bf3ecce/attachment.html