Trying to install sc3-plugins, but in NixOS I don't understand packaging or C

I’d like to build a package for, or at least install, sc3-plugins.

So far I’ve only tried to follow the sc3-plugins README, which does not address NixOS packaging. The README indicates one should first check out the source code for SuperCollider and sc3-plugins. I assumed the version of SuperCollider checked out should match the version installed on my system via nixpkgs, which is 3.11.2, so I specified that in the first of these two commands:

git clone -b 3.11.2-BigSur --recursive
git clone --recursive

I installed fftw and cmake from nixpkgs. I then tried to run the steps in the sc3-plugins README:

cd sc3-plugins
mkdir build && cd build
cmake -DSC_PATH=../../supercollider -DCMAKE_BUILD_TYPE=Release -DSUPERNOVA=ON ..
cmake --build . --config Release
sudo cmake --build . --config Release --target install

The fourth of those five commands was unable to find fftw:

Linking CXX shared module
/nix/store/5ddb4j8z84p6sjphr0kh6cbq5jd12ncs-binutils-2.35.1/bin/ld: cannot find -lFFTW3F_LIBRARY-NOTFOUND
collect2: error: ld returned 1 exit status
make[2]: *** [source/CMakeFiles/NCAnalysisUGens_supernova.dir/build.make:208: source/] Error 1
make[1]: *** [CMakeFiles/Makefile2:874: source/CMakeFiles/NCAnalysisUGens_supernova.dir/all] Error 2
make: *** [Makefile:159: all] Error 2

I see that, per its Wiki, NixOS makes finding C libraries weird. That’s about as much of that wiki article as I understood.

Any advice will be greatly appreciated.

(@asheshambasta, who has wrestled with sc3-plugins previously, may find this post of interest.)

1 Like

When I start working on a new package, I typically just skip to building it using a nix derivation rather than trying to use make/cmake directly.

I would recommend using asheshambasta’s derivation as a starting point. If the derivation fails to build the package you can drop into the build environment which should make dealing with C libraries easier. Nixpkgs/Create and debug packages - NixOS Wiki

1 Like

For most cmake builds, you need

nativeBuildInputs = [ cmake pkg-config ];

buildInputs = [ /* dependencies */ ];

there’s a pkg-config and cmake shellHook which will look through all of your dependencies, and expose .pc files through PKG_CONFIG_PATH and CMAKE_LIBRARY_PATH.

In general, it’s “easier” to jump straight to a nix derivation. If the upstream package follows best cmake practices, a nix build is generally just listing the correct src, nativeBuildInputs, and buildInputs.

One disadvantage is that nix-build always builds in a clean environment so it needs to start compiling from scratch each time the build fails. This is not usually a problem but it makes iteration length unbearable for very big projects, especially if the build fails near the end.

Fortunately, you can always switch to using nix-shell with your Nix package definition as mentioned above.

Or, if you want to start without writing any expression, you can enter an ad-hoc shell with the dependencies using nix-shell -p cmake pkg-config fftw … but you really cannot install a fftw library, see FAQ/I installed a library but my compiler is not finding it. Why? - NixOS Wiki


Well, I still can’t install it – but I did get it to build! (Derivation here.) Thank you so much!

I can build the derivation isolated in its own folder, but I’d like to build it from my nixpkgs fork like I believe I’m supposed to. I copied it to an appropriate place, and added an appropriate line to pkgs/top-level/all-packages.nix. When I build it, it takes less than a second to respond that something is wrong with a file I’ve never modified:

jeff@jbb-dell:nixpkgs-fork$ nix-build -A sc3-plugins
error: attempt to call something which is not a function but a set, at /home/jeff/nix/nixpkgs-f
jeff@jbb-dell:lib$ git log --author="JeffreyBenjaminBrown" customisation.nix
jeff@jbb-dell:lib$ pwd

Looking at your expression, you’re most likely not passing a function to callPackage. Most package nix expressions are of the form:

{ stdenv
# ... other inputs

stdenv.mkDerivation {

if you copied from your derivation that you linked, you most likely only have:

# no input attr set

stdenv.mkDerivation {

I think you were right! Now I can get nix-env to install it.

I still can’t use it, but I suspect it’s not a NixOS issue; I’m asking on the SuperCOllider forum.

Thanks for the help!

Hello again, my good Samaritan genius friends!

I had a long back and forth with the SC community, and got to the point where we think I’m running into a NixOS issue.

Here’s the Nix expession I’ve used to install sc3-plugins. (I don’t think it’s changed since the last time I mentioned it.) That builds in a manner dependent on the already-installed version of SuperCollider. In my case that’s SuperCollider version 3.11.2, installed exactly as packaged on the NixOS 21.05 channel.

When I boot the SuperCollider server, after configuring it to find sc3-plugins, it complains:

*** ERROR: dlopen ‘/home/jeff/.local/share/SuperCollider/Extensions/SC3-plugin-so-files/’ err ‘/nix/store/jsp3h3wpzc842j0rz61m5ly71ak6qgdn-glibc-2.32-54/lib/ version `GLIBC_2.33’ not found (required by /home/jeff/.local/share/SuperCollider/Extensions/SC3-plugin-so-files/’

I’m surprised that it wants glibc 2.33. When I grep for “glibc” or “ldd” (for some reaosn those are synonyms) in the sc3-plugins source code, I don’t find either anywhere. That would make me think that the 2.33 requirement is not hardcoded into sc3-plugins, but rather created by my system – except that my system only has 2.32.

At least I think my system only has 2.32, because I use the stable 21.05 channel, and the latest glibc packaged for that channel is 2.32, and that is indeed the version of ldd that I get when I ask my system for its version:

jeff@jbb-dell:Extensions$ nix-channel --list
jeff@jbb-dell:Extensions$ sudo nix-channel --list
[sudo] password for jeff:
jeff@jbb-dell:Extensions$ ldd --version
ldd (GNU libc) 2.32

Could it be that my system has some sneaky glibc 2.33 hidden somewhere, which is why sc3-plugins expects to be able to use it? If so, how can I make it available to SC and/or sc3-plugins? If not, does that mean I’ve got to switch to the unstable channel? Last year I did that and broke my system somehow – could keep using it but couldn’t rebuild it, which made it hard to use new software (maybe I got around it with nix-env, or maybe I just didn’t install new stuff – I can’t remember) – so I’m a little nervous about the idea of switching channels, but willing if that’s the thing to do.

It works! I just had to upgrade to nixos-unstable.

And I think I know what the problem was. nixos-stable uses SC 3.11.2, whereas unstable uses 3.12.1. I had installed SC through the nixos-stable channel, but the way I built sc3-plugins was by adding a package to the latest version of nixpkgs, which is (roughly? exactly?) equal to the nixos-unstable channel, and which uses 3.12.1. That newer version, I imagine, is what depends on glibc 2.33.

A million thanks, @jonringer, @jtojnar and @Princemachiavelli!


I opened a pull request to add the package to nixpkgs.

Now that was nice to read your progress and determination! Good job and thanks for sharing.