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

[Till Oliver Knoll]

Am 07.06.2011 um 00:05 schrieb Thiago Macieira <thiago at kde.org>:

> Em Monday, 6 de June de 2011, às 23:45:30, Till Oliver Knoll escreveu:
>> No need to set LD_LIBRARY_PATH or the like. 
> 
> It's a bad idea to ship your own Qt libraries on Linux. If you do that, you 
> have to ship ALL of the Qt libraries, including the ones you don't need.

I was actually more referring to my own application libraries in this context ;)

But anyway, I don't see your point - except the very obvious of library duplication which is totally against the idea of *shared libs* - why it is so bad to ship your own set of Qt libraries together with the application.

Somenone already posted some reasons why one might want to do so. In addition I was on a project where we had custom code inside Qt (now I call THIS a bad idea - but we really needed floating point precision for fonts already in Qt 3 ;) so no other choice than shipping your own set of Qt libs. No big deal with the help of ldd ;) 

> Qt 
> might want to load the platform plugin, which may link to other libraries.

So if one really wanted to use this "platform plugin" then yes, go ahead and ship its dependencies.

But to be honest I don't even know what this platform plugin does. I imagine it integrates to KDE/Gnome and hence links to those "external" libs?

I agree that in this case it would probably not feasible to ship ALL dependencies (and I guess the "platform plugin" is Linux specific? Haven't checked the plugin folder for a while on Mac ;)
> 
> And you need to set LD_LIBRARY_PATH.

I don't see why, except for the security case that you want to make sure that really only YOUR set of libs is picked up at runtime.

I don't have a reference at hands, but as I already mentioned I think rpath really takes precedence over LD-LIBRARY_PATH. And I could imagine even over /usr/lib etc.

And note that in combination with $ORIGIN this really results in an *absolute* path (good!), so it is not possible to try to "inject" malicious libs via relative paths.

Or in other words: you get the same behaviour as on Windows, when you place your DLLs into the same directory as the exe. Those DLLs are always picked up first in the "DLL search path" (disclaimer: I haven't ckecked what happens with "manifested" libraries, in which order they are picked up: if specified in a manifest I guess they go first...).

But for the case to "get all dependencies picked up properly" - your own application libs for sure - on the target system rpath in combination with $ORIGIN works like a charm - as proven by practise ;)

And it goes without saying that when you ship the Qt libs as well that you would programatically set the Qt plugin path.

So I still don't see why LD_LIBRARY_PATH would be needed to setup a "self-containing application package", assuming that "rpath takes precedence over LD_LIBRARY_PATH" still holds.

Cheers, Oliver