[Development] Breaking up QtPlatformSupport

[Thiago Macieira]

Hello

After the alpha, I'd like to dismantle the QtPlatformSupport library and fix it 
properly. It should be broken up into smaller libraries or back into .pri files 
to be included.

I know this is not going to be a popular change, but please bear with me on 
the explanation:

Due to a mistake in the Qt buildsystem, the -Wl,--no-undefined is not used in 
plugin builds. This has led many plugins to be linked with undefined symbols 
because the necessary libraries were missing. In turn, that leads to 
surprising errors at runtime, like the application reporting that no platform 
plugins are present when libqxcb.so is clearly present.

QtPlatformSupport was initially a bunch of .pri files that were included from 
plugins and caused code to be built and linked into the plugins. The mistake 
in forgetting the dependent libraries was already present in those .pri files.

Then QtPlatformSupport was made into a convenience static lib (that is, a 
static library linked to a dynamic Qt, meant to be linked into another dynamic 
lib or plugin). Unlike any other convenience library out there, 
QtPlatformSupport is not meant to be used as a whole: plugins only need part 
of it.

When I re-added support for -Wl,--no-undefined, I noticed that many plugins 
failed to link because the dependent libs were missing. So I proceeded to add 
those libs.

Either way, with those libs being listed in .pri files inside 
QtPlatformSupport, all plugins linking to QtPlatformSupport link to those 
libs. That includes stupid things like the directfb plugin linking to the X11 
libs.

To make matters worse, a well-intentioned change (change 18023[1]) removed the 
libs from the .pri files. That, of course, meant that the plugins would fail to 
load unless the libs are listed in the plugins' .pro files. That change was 
made.

However, the plugins STILL DON'T LINK with -Wl,--no-undefined. The reason for 
that is because QtPlatformSupport is a static library: the order of libraries 
listed in the command-line is relevant. qmake does the right thing when the 
libraries are listed as dependent in the libQtPlatformSupport.prl file. I asked 
ossi on IRC and we cannot find a way to set the library order to the right one, 
unless the libs are listed in the .pri .LIBS.

Conclusion: since the libs must be listed when creating the static lib, the 
only way to avoid having DirectFB link to X11 is to break up QtPlatformSupport 
into smaller libs.

This will be hard to do with qmake, so the easier way out is to remove the .a 
altogether and use .pri files only. That requires moving the Wayland platform 
plugin back into qtbase.

[1] https://codereview.qt-project.org/18023

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120311/dab292ab/attachment.sig>