Cannot mix incompatible Qt libraries (on KDE and Ubuntu) #32

almarklein opened this Issue Oct 8, 2013 · 37 comments


None yet

This is a common problem when applications come with their own Qt library, as is the case with (ana)conda. I have encountered this with Pyzo and the binaries for IEP. I find this error particularly easy to reproduce on a Kubuntu box.


From what I understood, this is caused because styles and/or plugins are attempted to be loaded, but these depend on another version of Qt, causing a clash.


Disable looking for plugins. This needs to be done in two ways:

  • there needs to be a qt.conf next to the executable that has this content: "[Paths]\nPlugins = '.'\n"
  • before creating the application object, one needs to do QtGui.QApplication.setLibraryPaths([]). The effect of the latter seems also be achievable by instead setting the environment variable "QT_PLUGIN_PATH" to an empty string.

Side effects

Unfortunately, when disabling the plugins, the app will look less native. No oxygen theme on KDE, no integration of the menu bar on Unity.

asmeurer commented Oct 8, 2013

Those don't sound like good side effects. We get a lot of complaints about qt apps not looking good in Linux. Can this problem be solved by compiling qt on a machine that has kde and gnome installed?


The addition of the "gtkstyle" option ( would make the application look native on GTK based systems, so that would already help a lot.

For Unity, you now have this Mac-like menu bar, but (as I understand it) this goes via the plugin mechanism and is therefore problematic if you bring your own Qt libs. It could be that building on a machine with Unity would solve this, but I don't know enough about Qt to be for sure.

Similar for KDE, it might help building on Kubuntu, but you would have to try.


Of course, if you build on exacty the same OS, you do not have to disable the plugins, and things would just work. But building such specific versions would probably be the task of the maintainers for that particular distribution.


For Linux, we build on the lowest common denominator (CentOs 5 I believe, or maybe 6). @ilanschnell would have to confirm, but I suspect building multiple variants of QT for various flavors of Linux would be outside the realm of Continuum support, unless someone is willing to pay for it. But of course, people are more than welcome to build their own binaries and upload them to binstar.

But if it were somehow possible to install all those at once and automatically get support for them with one binary, that would be awesome. It would require a fair bit of work and testing, though.


Thinking out loud here, so this is probably a bad idea, but it should be possible to create a build of PySide that hooks into the native Qt libraries installed on a system. So you could for instance ship this native-based version of PySide, as well as the conventional PySide with Qt as a fallback.

User can then do sudo apt-get install qt4 or similar in order to use native Qt.

Edit: ah, no, PySide is of course build against a particular version of PySide, so this wont work :)


building multiple variants of QT for various flavors of Linux would be outside the realm of Continuum

It would also mean that conda should be able to distinguish between multiple flavors of Linux.

liftoff commented Oct 25, 2013

Just to chime in on this bug: I cannot get spyder to run on Ubuntu 13.10:

riskable@enterprise:/opt/anaconda/bin $ spyder
Cannot mix incompatible Qt library (version 0x40804) with this library (version 0x40805)
Aborted (core dumped)

I tried all the proposed solutions mentioned earlier in this bug report but none of them work (qt.conf, setting QT_PLUGIN_PATH="", etc). This is with Anaconda 1.7.0 which I just downloaded a few minutes ago.


@liftoff Did you place the qt.conf next to the executable? And the content should be:

Plugins = '.'
liftoff commented Oct 28, 2013

@almarklein Yes, I tried that. It didn't work.


@liftoff Could you try the binary for IEP? I tested it to work on Kubuntu and it would be interesting to see whether it works on your machine:

liftoff commented Oct 29, 2013

I just downloaded the 64-bit IEP tarball and tried it out... Works fine. No QT issues.


I am glad to hear that :) So there is probably a mismatch somewhere ...

onnodb commented Nov 26, 2013

Ran into this issue when trying to use Mayavi on Kubuntu 13.10 x64, Anaconda 1.8.0 (64-bit). Indeed, Almar's fix works fine; just wanted to stress that you need both a qt.conf file under anaconda/bin/ (next to the python executable), as well as an empty QT_PLUGIN_PATH environment variable. I missed that at first :-)

Everything working OK now; thanks a lot Almar!

maxeywen commented May 4, 2014

i would like to try this fix as i have just loaded Anaconda for a class and am getting this same error

Cannot mix incompatible Qt library (version 0x40803) with this library (version 0x40805)
Aborted (core dumped)

2 questions:

  1. when you say put qt.conf "next to" the executable, do you just mean in the same /bin folder? Or does it mean something more?
  2. QT_PLUGIN_PATH environment variable .... which file is this in? I was guessing qtconfig but since gedit can not read that file I think that guess is incorrect

PS Did visit the continuumIO support site only to find "spyder may not run properly on linux".

asmeurer commented May 5, 2014

A lot of qt issues are being fixed because we are switching to pyqt. You can see if conda install pyqt makes your problems go away.



when you say put qt.conf "next to" the executable, do you just mean in the same /bin folder?

Yes, it should be in the same folder as the exe.

QT_PLUGIN_PATH environment variable .... which file is this in?

It depends on the OS how you should set the environment variable. Just google "set environment variable" :) If you use Pyzo, it sets the variable for you.


@asmeurer awesome to hear that you are working on solutions to these problems!


This problem is still present in Anaconda 2.0 and it prevents me to test Spyder with it because I work with KDE.

I solved it by compiling Qt with dbus support. This is needed by oxygen (the KDE default theme) to draw windows borders and buttons. The lack of libQtDBus makes oxygen to look for it on the system and then comes the Cannot mix incompatible Qt libraries message, which means the linker is mixing Anaconda and system ones.

I suggested this solution to @ilanschnell last year, and today I tested it on my system and found it works correctly. I'll create a PR for it against the conda-recipes repo.

Edit: To test it I built and installed Qt with conda on my root environment (it took an eternity on my poor netbook :-)

@ccordoba12 ccordoba12 added a commit to ccordoba12/conda-recipes that referenced this issue Jun 2, 2014
@ccordoba12 ccordoba12 Compile Qt with Dbus support
- with this, Spyder and IPython qtconsole work correctly under KDE.
- The lack of libQtDBus in Anaconda makes Oxygen (the default KDE theme)
to look for it on the system, which causes an incompatible mix between
Anaconda and system Qt libraries.
- Fixes ContinuumIO/anaconda-issues#32
@ccordoba12 ccordoba12 referenced this issue in conda/conda-recipes Jun 2, 2014

Compile Qt with Dbus support on Linux #128

remram44 commented Jun 4, 2014

I'm affected by this as well, on Debian Jessie (testing) i386 with KDE.

@twiecki twiecki referenced this issue in glue-viz/glue Jun 13, 2014

Qt incompatibility #366


@asmeurer I can confirm that with pyqt4, one does not need qt.conf and QT_PLUGIN_PATH for an app to work. However, I also see that the app still does not look native (e.g. no integration with Unity menu bar). I assume that PyQt4 does some magic by itself to prevent mixing with the system qt libraries, and that the non-native look is expected?

BTW: I can also confirm that the qt.conf is still necessary on KDE, as @ccordoba12 indicates.


This is still an issue on kubuntu.

It seems that 3.4 need QT_PLUGIN_PATH to be set (but does not depend on qt.conf) where as 2.7 is the opposite.

I would argue that the qt recipe should install qt.conf and activate should set the enviromental variable.


Hi there,
I'm having this issue on kubuntu. I'm not using spyder, but it seems I'm not able to use matplotlib correctly. I installed matplotlib with conda on my kubuntu environment and I get the:

Cannot mix incompatible Qt library (version 0x40806) with this library (version 0x40805)

everytime I try to create a plot with it. I can produce output figures by changing to the svg backend, but I can't display plots, e.g., on the ipython notebook.

It isn't clear to me by reading the issue history if there's some workaround that would fix that. I tried a few things (unset QT_PLUGIN_PATH, or installing pyqt) that didn't worked. Are there any known fixes for this for matplotlib in kubuntu with anaconda?

fergalm commented Oct 29, 2014

For what it's worth: I just downloaded Anaconda 2.1.0 for 64 bit Linux on kubuntu 12.04. Spyder wouldn't load, giving the "incompatible Qt library" error. The QT_PLUGIN_PATH fix didn't work, but putting the qt.conf file in ~/anaconda/bin solved the problem for me


As a side note is a wrapper that makes sure a) qt.conf exists and b) manages the plugin ENV for you


is this issue fixed? Or are the workarounds lying around sufficient to avoid this problem?


I haven't tried any work around (except changing the backend), but the issue is still present. I'm using Kubuntu 14.10 and the latest version of Anaconda.


@asmeurer Can this be re-opened?


@tacaswell I fixed this one almost six monhs ago. The problem is Contiuum guys have not updated Qt to 4.8.6, which includes my fixes. They are still using 4.8.5, I don't know why.

marscher commented Dec 8, 2014

maybe because they would have to rebuild all stuff linking against QT?


Yes, of course. But AFAIK it's not that much: PyQt4 and ... I don't know
what else (at least as part of Anaconda :-)

El 08/12/14 a las 09:05, Martin K. Scherer escribió:

maybe because they would have to rebuild all stuff linking against QT?

Reply to this email directly or view it on GitHub
#32 (comment).


I ``solved'' by moving all anaconda's Qt libraries in a different place:

cd anaconda/lib
mkdir oldqt
mv libQt* oldqt -v

I think that only the OS libraries are used now,
and anaconda's spyder and matplotlib are working fine.

I'm using netrunner 14, with kde 4.13.0 and Qt 4.8.6

This is not a clean solution,
a better solution would be that the qt package be installed only if needed,
best would be that it does not look around for OS libraries at all.


@astyonax beware that this situation has a high risk of errors when there are incompatibility problems; e.g. when PyQy4 is build on another version of Qt than is present on your system.

best would be that it does not look around for OS libraries at all.

That's basically what we try to achieve with the qt.conf and QT_PLUGIN_PATH.


I was indeed quite surprised that my workaround is working,
but I'm new to anaconda, and I was looking for a simple solution to get used to get used to it.

btw: I did not want to set qt.conf and QT_PLUGIN_PATH because I have to remember if an app is in anaconda or not.

ripopov commented Jan 24, 2015

Solution with qt.conf in ~/anaconda/bin/ worked for me. Why it is not implemented in installer? - Lost some time trying to fix this in Kubuntu 14.10.

@ccordoba12 ccordoba12 added the Linux label Feb 14, 2015

Today ran to this issue again (what a nightmare) on OSX. I double-checked that I had all the fixes in place, to no avail. Then I saw that there was a directory called imageformats that I'd not seen before. Apparently the loading of these libs pulled in the system Qt libs, and the simple solution was simply to remove this directory.

Granted, this was for an app frozen with cx_Freeze (and on OSX with PySide). Anaconda may be unaffected. Still sharing in the hope it may be useful to someone.


For anyone still running into this problem, the solution is now simply:

conda update conda
conda update anaconda
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment