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

[Thiago Macieira]

Em Tuesday, 7 de June de 2011, às 11:12:04, Craig.Scott at csiro.au escreveu:
> On 07/06/2011, at 8:05 AM, Thiago Macieira wrote:
> > It's a bad idea to ship your own Qt libraries on Linux.
> 
> Well, in reality if you want to use anything beyond Qt 4.2 features, you
> don't really have a choice but to ship the Qt libraries if you want to make
> truly portable binary packages on linux. If you want recent Qt features,

The interesting thing is that reality contradicts what you called "reality" 
above.

Take this package as an example: 
http://download.skype.com/linux/skype-2.2.0.35.tar.bz2

It's a non-LSB package that requires Qt at a version later than 4.2 and works 
just fine on most recent distros. The fact is that they don't need to bother 
with support for very old distros, which the LSB still supports and even 
targets.

Another package that seems to contradict your concept of "reality" is a much 
more complex one and it doesn't even have RPMs and DEBs for the mainstream 
distros. You can download it from here:
	http://get.qt.nokia.com/qtsdk/Qt_SDK_Lin32_offline_v1_1_1_en.run
	http://get.qt.nokia.com/qtsdk/Qt_SDK_Lin64_offline_v1_1_1_en.run

> that means you have to build on a relatively recent linux distribution, but
> then the packages won't work on older distributions and this matters to a
> significant proportion of users (eg most corporate installs typically run
> RHEL or SuSE and these definitely tend to fall behind Qt's latest
> releases). Ideally, linux packages would be built to be LSB-compliant so
> that they would work on a wide variety of linux distributions, but even the
> latest LSB spec only requires Qt 4.2 (more on that in a separate post
> shortly).

LSB has lost track of what's recent. Just take a mildly old / relatively 
recent distribution (like the latest Debian stable) and build there. The 
binaries will run on any distribution that is newer. Two good benchmarks to 
judge the age and suitability of running the binaries you build are the 
versions of glibc and gcc.

> > If you do that, you have to ship ALL of the Qt libraries, including the
> > ones you don't need. Qt might want to load the platform plugin, which
> > may link to other libraries.
> 
> This is not true. You first work out which Qt libraries you need directly.

Then include the ones you don't need either, so why the extra effort? See 
below.

> Then look at what other Qt libraries they depend on using a tool like ldd.
> If you want to include the Qt plugins (which you might not actually need,
> depending on what your application does), then you simply do the same thing
> - use ldd to see what they depend on and ensure you include those in your
> package too. It's actually relatively easy to work out what you need to
> include. As long as you preserve the directory hierarchy, it all works
> seamlessly. We've been doing this for years without problems.

You're forgetting that Qt, at runtime, will try to open system plugins like 
the style and platform plugins for GUI, Phonon and WebKit. Those may link to 
libraries you didn't include in your build.

Loading Qt libraries from two different builds in memory will cause crashes. So 
you have to provide the libraries that the system plugins may want to use 
anyway.

> > And you need to set LD_LIBRARY_PATH.
> 
> There are cases where you won't need to, but without it, it does open up the
> opportunity for your binaries to pick up a system-provided Qt library that
> you may have missed and this can lead to all sorts of hard-to-trace bugs if
> you don't realise that's what's happening. I'd personally prefer to see
> LD_LIBRARY_PATH and QT_PLUGIN_PATH set before I ran the binary, if only for
> preventing this potential problem.

Because of the plugin issue above, you need to set LD_LIBRARY_PATH. You need 
it to apply even to the system plugins, which will not have your $ORIGIN. 
Therefore, you need to set LD_LIBRARY_PATH if you want to run against a 
locally-provided Qt. That's what Creator used to do and will do again, after 
we detected this very issue.

So you have two options:
 a) don't ship any Qt libraries, like Skype
 b) ship all Qt libraries and your main program is a script, like Creator

-- 
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/9de0fee7/attachment-0001.bin