How can I fix an apparent Qt4 / Qt5 conflict?

Question

I recently installed Qt4 even though I already had some Qt5 libraries installed, because an application seemed to require Qt4. Tragically, that application also used mayavi, which would now segfault when it tried to import its mlab module. I managed to isolate the cause of the segfault to the following imports, both of which are necessary to cause the crash:

me@Bedrock:~$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import vtk
>>> from pyface import api as pyface
QMetaType::registerType: Binary compatibility break -- Size mismatch for     type 'QUuid' [30]. Previously registered size 16, now registering size 0.
Aborted (core dumped)
me@Bedrock:~$

Googling around has led to some suggestions as to how to set environment variables in .bashrc :

export QTCHOOSER_RUNTOOL=qtconfig
export QT_SELECT=4
export QT_API='pyside'
export ETS_TOOLKIT='qt4'

I've used these, somewhat blindly, but without success.

Am I correct in believing my problems are due to a Qt4/Qt5 conflict, and if so, what should I do about it?

============================================================================= I've investigated a little further. I now can get this crash with the following two imports:

me@Bedrock:~/Downloads/temp3/mne-python$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from vtk.vtkCommonCore import *
>>> from PySide.QtGui import *
QMetaType::registerType: Binary compatibility break -- Size mismatch for   type 'QUuid' [30]. Previously registered size 16, now registering size 0.
Aborted (core dumped)

vtk.vtkCommonCorecontains a single line, which imports vtkCommonCorePython, and this is an .so file.

Similarly, PySide.QtGui is also a .so file.

So, my next step was to see which .so files /usr/local/lib/python2.7/dist-packages/PySide/QtGui.so and /usr/lib/python2.7/dist-packages/vtk/vtkCommonCorePython.x86_64-linux-gnu.so depend upon.

What I found was this:

me@Bedrock:/usr/lib/python2.7/dist-packages/vtk$ ldd -v vtkCommonCorePython.x86_64-linux-gnu.so 
    linux-vdso.so.1 =>  (0x00007fff28fc0000)
    libvtkCommonCorePython27D-6.2.so.6.2 => /usr/lib/x86_64-linux-gnu/libvtkCommonCorePython27D-6.2.so.6.2 (0x00007f0488925000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f04885a2000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f04881d9000)
    libvtkWrappingPython27Core-6.2.so.6.2 => /usr/lib/x86_64-linux-gnu/libvtkWrappingPython27Core-6.2.so.6.2 (0x00007f0487fac000)
    libvtkCommonCore-6.2.so.6.2 => /usr/lib/x86_64-linux-gnu/libvtkCommonCore-6.2.so.6.2 (0x00007f0487a7d000)
    libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007f04874ef000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f04871e6000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f0486fcf000)
    /lib64/ld-linux-x86-64.so.2 (0x000055b9eee1f000)
    libvtksys-6.2.so.6.2 => /usr/lib/x86_64-linux-gnu/libvtksys-6.2.so.6.2 (0x00007f0486d8a000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0486b6c000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f0486952000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f048674e000)
    libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f048654a000)

and this:

me@Bedrock:/usr/local/lib/python2.7/dist-packages/PySide$ ldd -v /usr/local/lib/python2.7/dist-packages/PySide/QtGui.so
    linux-vdso.so.1 =>  (0x00007fff37bfc000)
    libpyside-python2.7.so.1.2 (0x00007ff4672cf000)
    libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007ff466cfa000)
    libshiboken-python2.7.so.1.2 (0x00007ff466ac6000)
    libQtGui.so.4 => /usr/lib/x86_64-linux-gnu/libQtGui.so.4 (0x00007ff465dd2000)
    libQtCore.so.4 => /usr/lib/x86_64-linux-gnu/libQtCore.so.4 (0x00007ff4658de000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff46555c000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff465346000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff464f7c000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff464d5f000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ff464b45000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff464940000)
    libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007ff46473d000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff464434000)
    libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007ff4641f0000)
    libaudio.so.2 => /usr/lib/x86_64-linux-gnu/libaudio.so.2 (0x00007ff463fd7000)
    libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007ff463cc6000)
    libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007ff463aa0000)
    libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007ff4637f6000)
    libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007ff4635a3000)
    libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007ff46339a000)
    libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007ff463180000)
    libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007ff462f70000)
    libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007ff462d65000)
    libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007ff462b53000)
    libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007ff462819000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff462610000)
/lib64/ld-linux-x86-64.so.2 (0x000055bd99ece000)
    libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007ff4623e7000)
    libXt.so.6 => /usr/lib/x86_64-linux-gnu/libXt.so.6 (0x00007ff46217d000)
    libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007ff461f79000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007ff461d09000)
    libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007ff461b00000)
    libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007ff4618fb000)
    libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007ff4616d8000)
    libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007ff4614d2000)

Only /usr/local/lib/python2.7/dist-packages/PySide/QtGui.so seems to have any direct connection to the Qt libraries, so I don't understand how/why the vtk import interferes with anything Qt related.

Finally, I became curious about which version of Qt the /usr/lib/x86_64-linux-gnu/libQt...so files were using. So, I tried this:

me@Bedrock:~$ qmake --version
QMake version 2.01a
Using Qt version 4.8.7 in /usr/lib/x86_64-linux-gnu

I also checked my version of vtk

>>> vtk.VTK_MAJOR_VERSION
6
>>> vtk.VTK_MINOR_VERSION
2
>>>

and, separately, my version of PySide:

>>> import PySide
>>> PySide.__version__
'1.2.4'

At this point, I'm only more puzzled. Is my problem a Qt4/Qt5 conflict? (I think so) If not, why do I get Seg Faults with the error :

QMetaType::registerType: Binary compatibility break -- Size mismatch for       type 'QUuid' [30]. Previously registered size 16, now registering size 0.
    Aborted (core dumped)

If so, why do I only seem to be using one version of Qt? Most importantly, how can I fix this?

score 0 · Accepted Answer · answered Mar 22 '17 at 15:07

0

With default configurations of Qt builds, a given process can only use one version of Qt. If you're loading a Python module that uses Qt 5, and another that uses Qt 4, there will be issues as plenty of symbols overlap.

To use Qt 4 in parallel with Qt 5 in an application, you must compile one of the Qt versions in its own namespace, and rebuild the module(s) that use that Qt version. That way the symbols won't clash and the same process can use multiple Qt versions.

answered Mar 22 '17 at 15:07

Kuba hasn't forgotten Monica

95,931
16
151
313

I tried uninstalling first (sudo make uninstall), but the problem still persists. There are other Qt4 files on my machine. So, right now, I''m a little perplexed. I may go through /var/lib/dpkg/info to look for anything installed at the right time and manually delete them. But, I fear that may buy me more problems than it solves.... – user1245262 Mar 23 '17 at 06:07
Do not uninstall anything! Qt is designed so that multiple versions can coexist. It's entirely normal to have more than one version installed, e.g. on my development system I have about 20 installed Qt versions at the moment. You're also trying to work around the package manager, possibly corrupting its state: don't do that. You're not meant to! – Kuba hasn't forgotten Monica Mar 23 '17 at 15:15
In my answer, all I'm saying is that you should compile e.g. Qt 4 in its own namespace by passing `-qtnamespace Qt` to `configure`. Then build it. And then build the Qt-4 based python module using that version of Qt. And then it won't clash with Qt 5 that other modules use. – Kuba hasn't forgotten Monica Mar 23 '17 at 15:18
But I've already uninstalled and the problem has not changed (neither fixed, worse or merely different). What should I try to compile and where would it be? (Sorry if I'm being dense here, but as you can prob'ly tell, I'm a little out of my depth) – user1245262 Mar 24 '17 at 04:16
I've made some progress in isolating where the error/conflict arises, but don't know how informative what I'm looking at is. – user1245262 Mar 24 '17 at 05:27

How can I fix an apparent Qt4 / Qt5 conflict?

1 Answers1