Cannot mix incompatible Qt library

Help
1

Lately I am constantly getting this error when running some Qt software.

Cannot mix incompatible Qt library (5.15.7) with this library (5.15.9)

There are several issues on github about it but they’ve been closed:

There is also a topic here that has no replies:

The solutions generally involve finding old packages and removing them. This makes me question everything I thought I knew about nix. I thought one of the main features of nix packages was that you could run multiple versions of the same package. I generally don’t even “install” packages but run them using “nix run”. I’ve ran the garbage collector even though I shouldn’t have to and that still doesn’t fix this problem. I don’t have this problem with anything else other than Qt packages. It seems weird and very wrong that adding something to my nix store could break something else that was working fine before. It seems like that these types of packages should be flagged or something. Can someone please help me understand why this happens and if there is a workaround other than going on a wild goose chase trying to find packages to remove? Thanks.

1 Like
2

Cannot mix incompatible Qt library (5.15.10) with this library (5.15.9)

I’m also getting this with the current “unstable” packages. I haven’t found any way around it yet… :slightly_frowning_face:
I was running Qt Creator and Clion in a nix-shell with the Qt dev packages.

3

Digging back this, because I had this recently (between 5.15.12 and 5.15.14) with freecad. I’m using home-manager as a nixos module. Turns out an old version of freecad was installed in the only generation listed by nix-env --list-generations (which was from 2 months ago, maybe when I installed the machine) and one was installed by home-manager. The former took precedence.

The way I discovered it is via these commands:

# find the store of freecad
realpath $(which freecad)
# check if it really depends on an outdated qt, put there the path given by the previous command)
nix-store --query --requisites /nix/store/59j0wqnlg3brq2haqq944ddbyk39vcg0-freecad-0.21.2
# then check what makes this store path stays around
nix-store --query --referrers-closure /nix/store/59j0wqnlg3brq2haqq944ddbyk39vcg0-freecad-0.21.2

This gave me some store path like

/nix/store/sdvdp9g1942xjvl903ggjp83bzbhxz2a-env-manifest.nix
/nix/store/19dwzlm5jrd5j3in7imrsyiwyhd4fdpg-user-environment.drv
/nix/store/lplh4wkl9x98l6bk3yiq2dxj0rlz6cry-user-environment

Then I guessed something was wrong with my profile listed by nix-env (but that was just my intuition, I don’t know how to get there in a more formal way). And sure enough, listing the bin folder in the current generation showed that freecad was installed there (it was supposed to be installed by home-manager). Removing it with nix-env fixed the issue.

nix-env is the new /usr/local :wink: But yeah, as choward said, this usually involves finding and upgrading or removing old packages. Some people had luck with nix flake update, other with nix-collect-garbage…

As from “why does it even matter that this package uses an old qt, I thought nixos was supposed to prevent this from happening?”, well I wholeheartedly agree, but apparently for Qt this is not the case. Some (incomplete) explanations: Mixing incompatible Qt library (version 0x50902) with this library (version 0x50901) · Issue #30551 · NixOS/nixpkgs · GitHub

The threads you linked in the first post are also useful. Everything seems to be closed, but the problem is probably not fixed yet

1 Like
4

Ok, I was having this message in a flake while developing, I require rviz2 to visualize something and it had this error:

Cannot mix incompatible Qt library (5.15.15) with this library (5.15.14)

I solved it by explicitly installing qt explicitly and importing the LD path

{
  inputs = {
    nix-ros-overlay.url = "github:lopsided98/nix-ros-overlay/master";
    nixpkgs.follows = "nix-ros-overlay/nixpkgs";  # IMPORTANT!!!
  };
  outputs = { self, nix-ros-overlay, nixpkgs }:
    nix-ros-overlay.inputs.flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = import nixpkgs {
          inherit system;
          overlays = [ nix-ros-overlay.overlays.default ];
        };
        installPkgs = [
            pkgs.colcon
            # pkgs.libGL
            pkgs.qt5Full
            # ... other non-ROS packages
            (with pkgs.rosPackages.jazzy; buildEnv {
              paths = [
                ros-core
                rviz2
                # ... other ROS packages
              ];
            })
          ];
      in {
        devShells.default = pkgs.mkShell {
          name = "AI camera";
          packages = installPkgs;

          env = {
            LD_LIBRARY_PATH = "${
              pkgs.lib.makeLibraryPath installPkgs
            }:/run/opengl-driver/lib:/run/opengl-driver-32/lib";
          };
        };
      });
  nixConfig = {
    extra-substituters = [ "https://ros.cachix.org" ];
    extra-trusted-public-keys = [ "ros.cachix.org-1:dSyZxI8geDCJrwgvCOHDoAfOm5sV1wCPjBkKL+38Rvo=" ];
  };
}

The relevant parts are the definition of the packages to install (variable installPkgs) which then I use to install the packages and to add them to LD_PATH, not all require to be there, it was just the quickest way to use it for now.

I add this answer because I didn’t found it anywhere, I had a hunch because of how to use cuda inside a shell and it worked the same way.

5

To save future me some time here: All the garbage-collect in the world won’t help. NixOS doesn’t scan your nix store for qt libraries, but your environment.

There is a great tool, which will find the issue within seconds: nix-tree: GitHub - utdemir/nix-tree: Interactively browse dependency graphs of Nix derivations.

  • Run the tool, search qtbase with /
  • There should be two conflicting versions. Having multiple major versions is apparently common, you need to look out for multiple variants of the same major version.
  • Enter lets you jump into the dependency tree in a place where this library is used.
  • Press w to find out where this version of the library is used, i.e. all transitive referrers.

The last two times, your home-manager stuff was using a different version than your system stuff.

3 Likes
6

I am having this issue with unstable packages, sddm installed in system and kdenlive installed in home-manager (qt version 6.9.0 for sddm and 6.9.1 for kdenlive, as far as i can tell from nix-tree). But I am a nix newbie and I am not sure how to proceed in resolving the issue? Any help would be greatly appreciated. I guess I could switch to a tui login manager? I tried building without sddm and logging in manually but I still got the same error so i am guessing that i have to build, then reboot to that generation and remove all older generations that reference 6.9.0? Is there any way to force sddm to use 6.9.1 like kdenlive does?

7

Following up… Much of the information in my previous post about which packages were conflicting was incorrect. But the problem was the same. I believe old versions of kdenlive were conflicting with new versions. The problem was solved after I realized that sudo nix-collect-garbage -d cleaned up system generations and nix-collect-garbage -d cleaned up home manager generations and I had a whole bunch of home manager generations lying around. Once I rebooted to the newest generation, ran both of the above nix-collect-garbage commands then my qt incompatibilities with kdenlive vanished. I wish that this did not matter to NixOS. I thought that the whole point was that everything ran in it’s own space but I guess there is something funky about libQT? Still getting the hang of NixOS though, so could be my fault somehow?

8

Many things are possible, like you may have some imperatively managed (i.e. not by NixOS) service/desktop file that still points to old kdenlive. For example, if you click some checkbox to autostart some program on boot/login, that would cause exactly this sort of issue.

Either way it’s not really getting “fixed” by gc, rather gc would temporarily patch around whatever the real problem is - so you may encounter this again in the future.

9

You just saved me a sleepless night, thank you!

I’m on 25.11 and I have to use globalprotect-openconnect vpn from 25.05.

Why?: One of it’s dependencies (qtwebengine-5.15.19) was marked as insecure in 25.11 and is not built on hydra anymore. Thus it can’t be substituded. And it would take a whole day for me to build it. And I cant even be sure it builds.

But it breaks with Cannot mix incompatible Qt library (5.15.18) with this library (5.15.17)

Thanks to you I learned that I need to make sure there are no minor-version conflicts in qt-related stuff in the environment.

I ran it like this QT_PLUGIN_PATH='' NIXPKGS_QT5_QML_IMPORT_PATH='' gpclient and it worked. The window looked a bit off, but there’s just a url box and a button, no big deal. But for some apps this may be unacceptable.

gpclient executable’s wrapper uses the environment it’s called from and ADDS the necessary paths to QT_PLUGIN_PATH and NIXPKGS_QT5_QML_IMPORT_PATH. The problem is that the surrounding environment has the newer versions in these env-vars. And ADDING the older ones in the wrapper made it break.

There were 2 ways to fix it:

  • --set QT_PLUGIN_PATH and NIXPKGS_QT5_QML_IMPORT_PATH in the wrapper instead of --prefix
  • run the executable from an environment with empty QT_PLUGIN_PATH and NIXPKGS_QT5_QML_IMPORT_PATH, which is what I did for now