Qt Creator can't locate Qt libraries

[skyvine]

Issue description

When I try to run a Qt project it complains about linker errors:

:-1: error: cannot find -lQt5Widgets
:-1: error: cannot find -lQt5Gui
:-1: error: cannot find -lQt5Core
:-1: error: collect2: error: ld returned 1 exit status

This issue can be resolved by manually adding LIBS += -L/nix/store/${qtbase-hash-code}-qtbase-${qtbase-version}/lib to the .pro file, but this should not be necessary.

Steps to reproduce

1. Add qtcreator and qt5Full to your packages and run nixos-rebuild switch.
2. Create a new QtWidgets project in QtCreator
3. Accept all of the default options (with the Desktop kit)
4. Attempt to run the project

My QtCreator hash is b5lx1df8y5z8ing4f8fgf0gs777jq7m3 and my Qt5 hash is zcrx213vn6vrwrvp8j26xk7a3wmikky1.

Technical details

• System: NixOS 16.09.1803.40de598 (Flounder)
• Nix version: nix-env (Nix) 1.11.6
• Nixpkgs version: "16.09.1803.40de598"

[lheckemann]

Does this work if you launch qtcreator from within nix-shell -p qtcreator qt5Full ?

[bjornfor]

Yes, nix-shell -p qtcreator qt5Full [gnumake gcc gdb cmake] gives a working IDE.

However, QtQuick Controls 2.0 is missing (it does find QtQuick Controls (v1) though). I tried with this patch:

diff --git a/pkgs/development/libraries/qt-5/5.7/default.nix b/pkgs/development/libraries/qt-5/5.7/default.nix
index 85b38c6fc6..adc8b98202 100644
--- a/pkgs/development/libraries/qt-5/5.7/default.nix
+++ b/pkgs/development/libraries/qt-5/5.7/default.nix
@@ -99,8 +99,8 @@ let
       env = callPackage ../qt-env.nix {};
       full = env "qt-${qtbase.version}" [
         qtconnectivity qtdeclarative qtdoc qtgraphicaleffects
-        qtimageformats qtlocation qtmultimedia qtquickcontrols qtscript
-        qtsensors qtserialport qtsvg qttools qttranslations qtwayland
+        qtimageformats qtlocation qtmultimedia qtquickcontrols qtquickcontrols2
+        qtscript qtsensors qtserialport qtsvg qttools qttranslations qtwayland
         qtwebsockets qtx11extras qtxmlpatterns
       ];

(This adds 'qtquickcontrols2' to qt5Full). But it wasn't enough.

"QML_IMPORT_TRACE=1 qtcreator" is useful.

[skyvine]

I think I'm getting the same behavior as @bjornfor. When I launch it with nix-shell -p qtcreator qt5Full it works fine for a normal project. If I try to make a Qt Quick Controls 2 application then no kits are available for selection and I am unable to advance the GUI. If I try to make a Qt Qick Controls application then it appears to work fine (again, using all of the default options in the GUI with the Desktop kit and running with no changes to code).

[bjornfor]

@SaffronSnail: If you cannot select a "Qt Quick Controls 2" project, then there may be something else going on in your setup. I'm at least able to select / create such a probject and build it, but when trying to run it I get error.

You might want to (re)move ~/.config/Trolltech*, ~/.config/QtProject* to ensure no stale paths are being picked up. Also, unless you run "NIX_PROFILES= qtcreator", qt will also pick up modules from the profiles. Just FYI.

[bjornfor]

Ah, qtcreator itself is a wrapper script that sets QML2_IMPORT_PATH. Doh...(I hate wrappers.)

[bjornfor]

I'm testing rebuilding qt world by using --prefix instead of --set in the qt-wrappers. Will post PR when ready.

[bjornfor]

@SaffronSnail: On topic. Packages added to configuration.nix in environment.systemPackages are not expected to compose into development environment. It's by design. So this is basically "wontfix" :-/

[skyvine]

I'm not sure that I understand the design. My understanding is that the purpose of QtCreator, the application, is to build and run code using Qt libraries. What would be the purpose of installing the package if not to create and build projects?

Is there a different place I should add QtCreator to in order to get the "development version" of application?

[bjornfor]

Some developers think that it would lead to a lot of bug reports if development packages "found each other" by simply being installed in a profile. I agree to some extent, but I also think it would useful to have as an option. What would happen if you installed qtcreator and 3 different Qt versions? So the general idea is that if you want a development environment, you use nix-shell and/or write a Nix expression.

But if you want to try the dark side, you can probably set some environment variables to make packages installed in your profile "find each other". That basically makes your whole system a single big development environment.

I believe nix-shell -p qtcreator -p qt5.full is a (or should be -- it appears broken) supported way to obtain a development environment. Perhaps others have more ideas.

[skyvine]

I understand that you wouldn't want to make the paths to Qt globally available, because if I'm compiling some random project from my terminal I don't want to be searching the directories of all of Qt's dependencies. However, I would expect that when the QtCreator process is launched it has all of it's dependencies added, since that is required for the program to successfully execute basic functionality. Qt is a dependency of QtCreator just like Clang is, and QtCreator has no problem locating the Clang package to compile my code.

If you need to handle having different versions of Qt installed then the qtcreator package should have an option to specify the version of Qt that it relies on. This way, if the problem is that multiple users want different version they can all get what they want/expect by simply launching QtCreator with no extra effort required. If the problem is that an individual desires different versions of QtCreator then they simply need to install multiple versions of the package, and sort out the namespace collision by specifying alternate names for additional versions.

For now, I guess I'll just alias qtcreator to nix-shell -p qtcreator -p qt5.full so that I can use the package.

[lheckemann]

then the qtcreator package should have an option to specify the version of Qt that it relies on

It has such an option for specifying the Qt version that qtcreator itself builds with. However, it makes a lot of sense to keep that separate from the Qt version used by the projects worked on within qtcreator. This also wouldn't cover the case of non-qt libraries being used from within qtcreator.

One alternative option you may want to consider, which is the usual approach on NixOS for programs which need data from other packages at runtime and don't have the paths baked into them but go through a search path specified in an environment variable, is to make a wrapper for qtcreator that sets the appropriate environment variables (like nix-shell does) and install that.

[skyvine]

Hmm... ok, I agree that it doesn't make sense to automatically make libraries available for use even if the authors of the original program intended that way; qtcreator fits awkwardly into Nix because the authors of the program did not create a pure application. I take it the reason that it's able to locate my compiler with no problems is because the compiler path is "hardcoded" (by the machine) somewhere in /nix/store/hash-qtcreator-version/?

I started working on a wrapper script like you said, but then I started thinking about how this solution scales. Sure, this will give me access to qt but this doesn't really help if I build an application that depends on many different packages. I certainly don't want to have to write a separate wrapper for every project that I create.

I think that setting the LIBS argument as in the original post is actually the best solution, except for one problem: I don't want to have the hash code hardcoded into the configuration. I'd like to be able to build this project on any machine, not just my current workstation, but if I go to an earlier version of Nix which has compatible, but different, software then I would need to change the hash codes for all of my dependencies.

When writing nix expressions I can get the path to a package from a variable. I'm wondering if I can get the same functionality inside of qtcreator's .proj file. My first thought is to wrap qtcreator with a script that iterates through all of the packages that are currently active on the system and set environment variables with the following naming scheme: NIX_PKG_PATH_${prog_name}. That way I can say LIBS += -L$NIX_PKG_PATH_QT5FULL/lib Based on you experience with Nix, does this sound like a reasonable approach?

[bjornfor]

In release-17.03 you won't have to set LIBS. Tested just now. I added qtcreator, qt5.full, gcc, gdb, cmake, gnumake to my environment (with nix-env, should be the same as with environment.systemPackages). So qt finds itself.

I remember now that qt is special in nix due to how it looks up certain things relative to $NIX_PROFILES. (Confirmed with "QML_IMPORT_TRACE=1 qtcreator".) It won't find 3rd party libraries though.

AFAICT, how to compose development environment with qtcreator is an unsolved problem. Even nix-shell isn't a fully working solution due to qtcreator being a wrapper that overrides things like QML2_IMPORT_PATH.

[skyvine]

Great, I just updated and it does build the projects now... although I now get an error about plugins and OpenGL when I launch it. That doesn't pertain to this issue, however.

As far as composing development environments in qtcreator, I think that my idea to set environment variables based on package names has potential; I'm going to try it out and see how it goes. Either way, it appears that the issue I opened has been resolved. Thanks!

[schmittlauch]

Yes, nix-shell -p qtcreator qt5Full [gnumake gcc gdb cmake] gives a working IDE.

Just as I'm running into this myself right now: Did QtCreator find the Qt environment and qmake by itself or was something else necessary?
In my case, it can not find Qt and qmake in the path.

[schmittlauch]

A rm -rf ~/.config/QtProject* made QtCreator search the path from within the nix-shell again and now it found qmake in the path.

[wirew0rm]

All this information should be added in qtcreator's meta.longDescription imho.

For me even when removing the the configuration files it still finds an invalid qt5base which is in my path before qt5Full and refuses to add any projects. I usually grep the path for qt5full and add it manually in the qt version tab. But even then I'm only able to create qtWidget projects, QtQuick Projects still show "invalid kit" and complain about missing files on the command line.