Issue description
IMHO this is the most notable and irritating bug in Nix/NixOS. Basically, if there are multiple versions of the same QT plugin in /nix/store, _all_ QT applications which use that plugin will fail with "QT library version mismatch" error. I am wondering if there is a solution which doesn't require deleting older generations and lets you update the system regularly.
Steps to reproduce
Install multiple versions of QT;
Launch some QT-based applications.
balsoft
All 18 comments
See also:
jtojnar
on 31 Mar 2018
Perusing this real quick (haven't hit it yet) - the discussion at https://github.com/NixOS/nixpkgs/issues/17448#issuecomment-246200371 suggests this was believed to be fixed and just a side effect of leftovers from older installations? Seems like that isn't true.
The actual problem is with Qt's numerous plugins: these are (or can be) loaded from the system path. This would not be a problem if Qt had any notion of plugin versions, but it does not: Qt just loads whatever plugins it thinks it needs and segfaults be damned.
May be worthwhile to file something upstream to at least nudge Qt/KDE in the right direction if there's something to make it easier? I've been getting a bit involved with KDE and will keep this in mind...
jcrben
on 1 Apr 2018
cc @ttuegel
globin
on 2 Apr 2018
AFAIK, this is only a problem if you actually have multiple Qt versions installed. Old versions in the store are safe. If anyone has a test case showing otherwise, I will take a look.
On our end, there are two possible solutions. First, hardcode all plugin paths; I have a branch for this, but some things still don't work right, like input methods and themes. I haven't pushed that branch to completion because I don't think those things ever can work right. The second option is to override the Qt libraries through LD_LIBRARY_PATH like we do with libGL, i.e. link to /run/qt-5/lib. If we go that way, it will break Qt applications outside NixOS and draw the ire of the many people who have fought for years against the libGL hack. The advantage of the second option is that it will bring us in line with literally every other Linux distribution.
The hard truth is that the Qt philosophy of ABI compatibility and dynamic linking is completely incompatible with the Nix philosophy of static-dynamic linking. At this point, the only real resolution I can see is waiting for Snap or Flatpak to be available on NixOS.
ttuegel
on 2 Apr 2018
May be worthwhile to file something upstream to at least nudge Qt/KDE in the right direction if there's something to make it easier?
KDE plugins actually do the right thing! KDE plugins are Qt plugins with an extra data section of embedded JSON; if a KDE plugin has the wrong version, it just isn't loaded. This only mitigates the problem, though: the program doesn't segfault, but it's still missing plugins.
ttuegel
on 2 Apr 2018
See #37720
thall
on 3 Apr 2018
@ttuegel I am not sure if this works as a test case, but when I switched from 17.09 to 18.03, kdenlive segfaulted with Cannot mix incompatible QT library message, and nix-collect-garbage -d solved the issue. I am not an expert in Nix, but I though that collecting garbage only deleted the "old" store paths that are not used by current generation. Unfortunately, as I've already collected the garbage, I cannot provide any info about it. If this happens again, I'll definetely send a ping here.
balsoft
on 3 Apr 2018
@balsoft I'm not an expert but that would strike me as a serious bug in nix. Things that are garbage collected shouldn't be on the path in the first place. Are you sure the problem wasn't solved by the upgrade itself, or by uninstalling old versions installed by the user?
turion
on 4 Apr 2018
Haven't seen this issue since my 18.03 upgrade. Closing to keep Issues counter down.
balsoft
on 26 Jul 2018
Can you please re-open the issue?
I have the same "Cannot mix incompatible Qt library" problem with several programs, e.g.:
$ openscad
...
Cannot mix incompatible Qt library (version 0x50b01) with this library (version 0x50b03)
$ mubmle
...
Cannot mix incompatible Qt library (version 0x50b01) with this library (version 0x50b03)
$ nethack-qt
...
Cannot mix incompatible Qt library (version 0x50b01) with this library (version 0x50b03)
$ phototonic
...
Cannot mix incompatible Qt library (version 0x50b03) with this library (version 0x50b01)
Is there any way to make these programs work again?
rkoe
on 12 Mar 2019
@rkoe My understanding is that the problem is well summarized by https://github.com/NixOS/nixpkgs/issues/30551#issuecomment-345141502
To troubleshoot it, look at what is installed in your system (e.g. nix-env -q or NixOS configuration) and bringing an incompatible Qt, remove that.
veprbl
on 15 Mar 2019
Ok, so I've found that qt is both in the system- and user-environment:
/home/user/.nix-profile/bin/../lib/qt-5.10
/home/user/.nix-profile/bin/../lib/qt-5.11
/run/current-system/sw/bin/../lib/qt-5.11
Now, what? How can I find out, which programs cause this?
rkoe
on 15 Mar 2019
You can use nix-store --query --referrers $(readlink -f $path). But it is almost always better to upgrade all packages together when possible (even if just to reduce a number of versions in the store after GC).
jtojnar
on 15 Mar 2019
But which path should I use with the nix-store-call?
- I've uninstalled all programs referencing the path,
/home/user/.nix-profile/bin/../lib/qt-5.10points to, but this did not help. - In
/home/user/.nix-profile/bin/../lib/qt-5.11, there are many symlinks, pointing to many different nix-store-paths.
By the way: I've upgraded all packages, but the problem still exists.
rkoe
on 15 Mar 2019
@rkoe I had a similar situation. To make sure you catch all possible culprits, you can try what I outlined here (if you haven't already done so). The problem is not between 5.10 and 5.11, but between 5.11.1 and 5.11.3.
timor
on 15 Mar 2019
Ok, thanks, that may find the problematic package; and I guess I could then search for the program using it.
Whatever, in the meantime, I've manually uninstalled packages until the error disappeared. It's annoying that this has to be done manually, and there's no automatic way.
Curiously, after reinstalling the uninstalled packages, the error did not occur again -- which is strange, since upgrading did not solve it...
rkoe
on 17 Mar 2019
(To be) fixed in #54525 and #65399
veprbl
on 29 Jul 2019
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
nixos-discourse
on 30 Mar 2020
Related issues
vaibhavsagar
·
3Comments
chris-martin
·
3Comments
copumpkin
·
3Comments
rzetterberg
·
3Comments
ayyess
·
3Comments
Most helpful comment
(To be) fixed in #54525 and #65399