Missing ALSA headers in custom package

I am trying to build a package that requires alsa headers.
During the configure phase it fails with:

checking for alsa/asoundlib.h... no
configure: error: Missing ALSA headers

I have the following derivation definition:

{ lib, stdenv, fetchFromGitHub, autoconf, automake, alsaLib, libpulseaudio, libjack2, ... }: 

stdenv.mkDerivation rec {
  pname = "vban";
  version = "2.1.0";

  src = fetchFromGitHub {
    owner = "quiniouben";
    repo = pname;
    rev = "v${version}";
    sha256 = "0w6f54fbcafclhs9a5d9f3cf7b1rcm9p4hh3dgj2sbi4i7q5718k";

  nativeBuildInputs = [ autoconf automake ];
  builtInputs = [ alsaLib alsaLib.dev libpulseaudio libjack2 ];

  preConfigure = ''

  meta = with lib; {
    description = "VBAN protocol open-source implementation";
    homepage = "https://github.com/quiniouben/vban";
    license = licenses.gpl3;
    maintainers = with maintainers; [];
    platforms = platforms.unix;

Are the headers in another library altogether?
On debian the package I needed to install was libasound-dev, but that does not exist in nixpkgs.

Also are there any tricks to finding the right libraries when the debian package names are known?
How do I find out what package I need to install when something fails?

You have a typo in your derivation, try changing builtInputs to buildInputs.

Seems like that typo still makes it work, I didn’t even notice that and nix did not complain either.

Turns out I actually had to put the dev library into the nativeBuildInputs instead and it worked.

be aware, that alsaLib has been renamed to alsa-lib

so if you want to commit to unstable ( or rolling) today, you’ll need that change.

other packages/distros, sometimes the development .h headers come with the package, sometimes you need package-dev .

it really just depends on the package.

1 Like

You are generally allowed to pass extra attributes in function calls like this. Unfortunately, this means you will not get any errors if you mistype an attribute name that has a default value.

As for buildInputs vs. nativeBuildInputs, see this section of the manual for the difference: essentially, if it’s needed at build time, it goes in nativeBuildInputs, if it’s needed at run time, it goes in buildInputs.