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

[Thiago Macieira]

Em Tuesday, 7 de June de 2011, às 08:33:05, Till Oliver Knoll escreveu:
> 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 ;)

Ok, that is fine. Your own libraries, in a private dir, you can probably refer 
to via relative $ORIGIN. That's a good solution

> 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.

It's a bad idea because you have to ship them all, including the ones you 
don't need.

> > 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.

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. This 
plugin is not provided with Qt -- it's provided by the platform and it may 
link to other Qt libraries that your program doesn't directly use.

For that reason, and because loading Qt libraries from two different builds is 
an incredibly bad idea, you have to either ship all libraries or you're better 
off shipping none of them.

> 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 ;)

Yes, it's a Linux thing because only on Linux do we have systems built on top 
of Qt. We can't integrate with them from Qt: that would be a dependency 
reversal. So instead, we provide the hooks in the form of a plugin that will 
be loaded and the platform does the integration.

> > 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.

The plugin case. See more info in the other email.

> 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.

RPATH is obsolete. RUNPATH, the recommended ELF header entry, is overridden by 
LD_LIBRARY_PATH, not the other way around.

> 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.

It doesn't hold. And don't forget that your RPATH or RUNPATH doesn't apply to 
the system plugin.

-- 
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/20110607/bfcc26a7/attachment.bin