Missing ALSA headers in custom package

Help
1

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 = ''
    ./autogen.sh
  '';

  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?

2

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

3

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.

4

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

https://github.com/NixOS/nixpkgs/pull/126440
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
5

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.