Am 07.06.2011 um 00:05 schrieb Thiago Macieira <[email protected]>:

> 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
_______________________________________________
Qt5-feedback mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

Reply via email to