✗ GTK 3.0 development libraries are required for Linux development

Help
1

Hi,

I installed Flutter via Flutter version management ( FVM ). but I have problem with GTK 3.0 development libraries.

I tried to add the following in configuration.nix

  environment.systemPackages = with pkgs; [
        ...
        gcc
        gnumake
        at-spi2-core.dev
        clang
        cmake
        dbus.dev
        gtk3
        libdatrie
        libepoxy.dev
        libselinux
        libsepol
        libthai
        libxkbcommon
        ninja
        pcre
        pkg-config
        util-linux.dev
        xorg.libXdmcp
        xorg.libXtst
  ];

but when I run flutter doctor, it outputs

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.27.1, on NixOS 25.05 (Warbler) 6.11.11, locale en_US.UTF-8)
[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
[✗] Chrome - develop for the web (Cannot find Chrome executable at google-chrome)
    ! Cannot find Chrome. Try setting CHROME_EXECUTABLE to a Chrome executable.
[✗] Linux toolchain - develop for Linux desktop
    ✗ GTK 3.0 development libraries are required for Linux development.
      They are likely available from your distribution (e.g.: apt install libgtk-3-dev)
[✓] Android Studio (version 2024.2)
[✓] Connected device (1 available)
[✓] Network resources

! Doctor found issues in 2 categories.

I appreciate any help.

3

Definitely do not put gcc, libraries, compilers, build tooling, etc in your system packages. Use development shells instead.

4

Because I want the most updated stable version

5

I would like to have a global environment.

6

Doesn’t work on NixOS, sorry.

7

Not helpful with OP’s question and requirement. NixOS as a tool can do it. Keep your conventions to yourself and help if you can.

8

In a pinch, you can use a screwdriver as a hammer. Not doing so is more than a convention, however.

This proposed setup is just as contrary to the design of NixOS as that metaphor. If you want to use mutable software development tools, I recommend a container like Distrobox, which removes you from the constraints (and some of the benefits) of the Nix design.

9

Let’s just say I have other priorities in life right now, so I’d rather use a screwdriver I already have than spend a day on hammer shopping.

10

Back to OP’s original question, how I do get GTK 3.0 dev libraries on Nix? That’s how I landed here too.

11

The answer to the question depends on how you want to consume them.

In a generic dev shell, you add gtk3 to buildInputs.

In some programming languages, Nixpkgs has some functions for building shells specific to that environment, which will have their own documentation.

If you just want to use the instructions you find on the web for Ubuntu, use Distrobox, start an Ubuntu image, and run apt install libgtk-3-dev.

12

All right, what I want to do is have a profile-wide config file that has all my dev tools in one config file. Over the last 10 years, I have worked on over 100 projects, and I cannot maintain separate dev shells for each project.

13

Can I resolve this with home-manager perhaps? I’d really not want to have one dev shell defined just for flutter development.

14

Which programming languages? Python environments are different from Haskell environments are different from C++ environments are different from JS environments. Each of those build tools has been abused lovingly coerced into working in Nix’s unconventional configuration in its own way. There is no generic ‘just make it work’ other than stepping outside of Nix, which is why I keep bringing up Distrobox.

You could create such an environment just for C/C++ projects, probably, or just for Haskell projects, etc. But the environment variables you’d need to set and the config files you’d need to link together and so on would be a nightmare if you tried to do everything in one universal shell. It’s just not how this tool was intended to be used.

1 Like
15

Thanks for the clarification. I’m going to uninstall NixOS and go to Arch / Alpine Linux. If I have to spend one entire day tool shopping, then I might as well get a whole new toolbox.

1 Like
16

Conceptually this makes little sense IMO. Every project has its own pyproject.toml, or Cargo.toml, or go.mod, or whatever dependency specifications and build recipes. Creating a dev shell is simply listing out your dependencies for a given project, which will certainly differ by project. A global environment of possibly incompatible dependencies makes little sense in such a world.

For those interested in using the tools as intended, see Declarative shell environments with shell.nix — nix.dev documentation.

17

This is precisely my problem. Each project has pyproject.toml, cargo.toml,etc. and shell.nix is another file that I have to deal with, on top of the project spec.

On a lighter note, my use-case for Nix was to keep my dev and personal environment defined in one file. Turns out that isn’t the primary intended use for NixOS. So I’d like to pleasantly excuse myself.

18

You don’t need a separate dev shell for each project if you prefer that approach, but if something breaks, you’ll have to rely on your own skills to fix it. You can define your dev shell in your system flake configuration under outputs.devshell, and to use it, run my-nix-develop <dev-shell-name>. You don’t have to use Nix to manage all your package dependencies (not all languages are fully supported either), you can use it just for native dependencies. This way, you can get an experience similar to traditional Linux distributions.

my-nix-develop is a shell script, you can put in to your path

#!/usr/bin/env bash
nix develop /path/to/you/configuration/#"$1"

For example, if you’re developing a Python project, instead of using Nix to manage your Python packages, you could use uv instead. However, Python packages often require compilation and have native dependencies (such as pkg-config, gcc, gtk, dbus, etc.), which you can include in your dev shell to ensure they are available when needed.

Adding tools like gcc and make to your global environment isn’t necessarily a problem if you prefer it. While many people avoid this approach, it doesn’t mean you can’t do it. Conflict may exist, but you can always write a new dev shell.

Note that this approach it not reproducible and also conflicts with the Nix philosophy.

But if you want to do it, why not? It’s your system, after all.

19

It is a problem in that the correct envvars will not be set outside of a dev shell environment, and compilation of anything more complex than hello world becomes an exercise in masochism. Then they will complain that NixOS is broken rather than a result of misusing the tool.

Of course, if people want to reimplement stdenv by hand because they’re afraid to maintain a few lines of code in a shell.nix they’re absolutely welcome to do so :grin:

1 Like