[Development] Qt 4.8.7 built with linux-clang-64

[Thiago Macieira]

On Wednesday 22 July 2015 18:51:58 René J. V. Bertin wrote:
> > What is the build key with Clang? Does it list "gcc-4" or not?
> 
> I'm not sure I understand. The clang version I use does use headers from
> gcc-4 if that's of any relevance to your question.

The build key is a string that is assigned by configure to distinguish 
multiple, incompatible builds of Qt installed. When Qt 4.0 was released, this 
was a common occurrence:
 * GCC 3.3 was incompatible with GCC 3.4 and up
 * Qt 3's STL build was incompatible with the no-stl build and no one 
   realised that for Qt 4, that didn't apply
 * We used to support Sun Studio, IBM's Visual Age, HP's aCC and SGI's 
   mispPRO compilers in addition to GCC on, respectively, Solaris/SPARC, 
   AIX/POWER, HP-UX on both HP-PA and Itanium, IRIX/MIPS64.
 * In addition to the different compilers, we also supported Sun Studio builds 
   using the crappy default STL as well as Apache stlport.
 * of course, multiple architectures (as well as multilib)

When searching for plugins, Qt 4 looked for this build key and compared. If it 
was different, it would refuse to load the plugin.

This functionality was removed in Qt 5. We still store data in plugins, but 
it's just metadata now. We still refuse to load if the encoded Qt version is 
later than the current running one, but otherwise we punt the problems to the 
OS.

You can get the Qt 4 build key by running the QtCore library:

$ /usr/lib64/libQtCore.so.4                            
This is the QtCore library version 4.8.6
Copyright (C) 2014 Digia Plc and/or its subsidiary(-ies).
Contact: http://www.qt-project.org/legal

Build key:           x86_64 linux g++-4 full-config
Compat build key:    | x86_64 Linux g++-4 full-config |
[...]

> > Make sure it even searched those plugins in the first place. Try setting
> > QT_PLUGIN_PATH to `kde4-config --path qtplugins`.
> 
> It certainly looked like it didn't search those plugins, but that also seems
> a very unlikely reason. I used the exact same Debian/Ubuntu build &
> packaging scripts, edited only to use the linux-clang mkspecs instead of
> linux-g++ ... Unless of course the plugin path is set through the mkspecs
> files.

That depends on whether KDE was run before and saved its search paths in 
~/.config/Trolltech.conf.

> Is there a way to query the default plugin search path?

qmake -query QT_INSTALL_PLUGINS
kde4-config --path qtplugins

And the extra paths in ~/.config/Trolltech.conf.

> > Can you check
> > if the plugins have a .qtplugin section (objdump -h).
> > 
> > Actually, just run this on a plugin that won't load:
> > objdump -sj.qtplugin /path/to/plugin
> 
> Ok, thanks, saving this for future reference. As I said, debugging this
> would be very cumbersome (my Linux rig is severely underpowered for local
> Qt builds) so unless you'd want me to do this I'm going drop clang and set
> up the PPA to use gcc 5.1 instead.

I see no reason to spend time on Clang 3.5 with Qt 4.8 on Linux. I'd put my 
effort elsewhere where the result would be more valuable. Your work on OS X is 
appreciated.

It is probably working, since FreeBSD switched to Clang, so FreeBSD 10.1's 
ports carrying Qt are building with Clang 3.4. But I wouldn't spend time on 
this.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center