diwic / alsa-sys Goto Github PK

Hello, I got these message when I compiling a demo of alsa-rs by cross-compiling command cargo build --release --target=aarch64-unknown-linux-gnu

   Compiling alsa-sys v0.3.1
error: failed to run custom build command for `alsa-sys v0.3.1`

Caused by:
  process didn't exit successfully: `/works/alsa00/target/release/build/alsa-sys-b3fdfece193bda1f/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=ALSA_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_aarch64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_aarch64_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_aarch64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_aarch64_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_aarch64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_aarch64_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  thread 'main' panicked at 'pkg-config has not been configured to support cross-compilation.

  Install a sysroot for the target platform and configure it via
  PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_PATH, or install a
  cross-compiling wrapper for pkg-config and set it via
  PKG_CONFIG environment variable.', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/alsa-sys-0.3.1/build.rs:13:18
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

https://download.copr.fedorainfracloud.org/results/remilauzier/zemeroth/fedora-rawhide-x86_64/02304619-rust-alsa-sys/builder-live.log.gz

failures:

---- src/generated.rs - snd_ctl_elem_list_t (line 4803) stdout ----
error[E0425]: cannot find value element_index in this scope
--> src/generated.rs:4806:1
|
5 | element_index = snd_ctl_elem_list_get_index(&list, 2);
| ^^^^^^^^^^^^^ not found in this scope

error[E0425]: cannot find function snd_ctl_elem_list_get_index in this scope
--> src/generated.rs:4806:17
|
5 | element_index = snd_ctl_elem_list_get_index(&list, 2);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope
|
help: consider importing this function
|
4 | use alsa_sys::snd_ctl_elem_list_get_index;
|

error[E0425]: cannot find value list in this scope
--> src/generated.rs:4806:46
|
5 | element_index = snd_ctl_elem_list_get_index(&list, 2);
| ^^^^ not found in this scope

error: aborting due to 3 previous errors

Hi @diwic!

I'm currently implementing RustAudio/cpal#397 for ALSA and noticed that the aforementioned function is missing both from alsa and alsa-sys. Here's the docs for the function:

https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___s_w___params.html#ga912bad749f6317000eede607bb0bc935

This is required in order to allow CPAL to request timestamps of type SND_PCM_TSTAMP_TYPE_MONOTONIC_RAW.

Perhaps we can acquire this missing function by regenerating the bindings? I began work on regenerating the bindings a few months back at the CPAL repo not realising alsa-sys was moved here. During that process, I documented the command used to generate the bindings here:

https://github.com/RustAudio/cpal/pull/375/files#diff-fada08261a16e31b4cb0bdcc88a4662f

At least this way we can keep deps low (by not relying on bindgen at build time and avoiding problems like RustAudio/cpal#383) but still provide an easy way to regenerate bindings as required.

What are your thoughts?

Using bindgen, the build.rs would look something like

extern crate bindgen;
extern crate pkg_config;

use std::env;
use std::path::PathBuf;

fn main() {
    if let Err(e) = pkg_config::probe_library("alsa") {
        match e {
            pkg_config::Error::Failure { .. } => panic! (
                "Pkg-config failed - usually this is because alsa development headers are not installed.\n\n\
                For Fedora users:\n# dnf install alsa-lib-devel\n\n\
                For Debian/Ubuntu users:\n# apt-get install libasound2-dev\n\n\
                pkg_config details:\n{}",
                e
            ),
            _ => panic!("{}", e)
        }
    }
    if env::var_os("CARGO_FEATURE_USE_BINDGEN").is_some() {
        let bindings = bindgen::Builder::default()
            .header("wrapper.h")
            .prepend_enum_name(false)
            .generate()
            .expect("Unable to generate bindings");

        let out_path = PathBuf::from(env::var("OUT_DIR").unwrap());
        bindings
            .write_to_file(out_path.join("bindings.rs"))
            .expect("Couldn't write bindings!");
    }
}

I'm happy to knock up a PR if you accept this feature.

If pkg-conf is missing, the error message is just No such file or directory. A better error message would be desirable.

I am trying to build an embedded audio project using cpal, alsa-rs and alsa-sys. The target OS has an old GLibc and it might be tricky to upgrade. Building a static linked binary would be ideal.

At present alsa-sys hardwires statik(false) in build.rs so there's no way to static link.

I experimented with changing this to static(true) and building with armv7-unknown-linux-musleabihf toolchain. Something goes wrong with the link at this point, and various link errors appear like these:

  = note: /home/sam/src/organelle-ports-musl/output/host/lib/gcc/arm-buildroot-linux-musleabihf/10.3.0/../../../../arm-buildroot-linux-musleabihf/bin/ld: /home/sam/src/alsa-rs/synth-example/target/armv7-unknown-linux-musleabihf/debug/deps/libalsa_sys-aae2be964235592b.rlib(conf.o): in function `config_file_load':
          conf.c:(.text+0x4fa0): undefined reference to `__stat_time64'
          /home/sam/src/organelle-ports-musl/output/host/lib/gcc/arm-buildroot-linux-musleabihf/10.3.0/../../../../arm-buildroot-linux-musleabihf/bin/ld: /home/sam/src/alsa-rs/synth-example/target/armv7-unknown-linux-musleabihf/debug/deps/libalsa_sys-aae2be964235592b.rlib(conf.o): in function `snd_config_update_r':
          conf.c:(.text+0xc130): undefined reference to `__stat_time64'
          /home/sam/src/organelle-ports-musl/output/host/lib/gcc/arm-buildroot-linux-musleabihf/10.3.0/../../../../arm-buildroot-linux-musleabihf/bin/ld: /home/sam/src/alsa-rs/synth-example/target/armv7-unknown-linux-musleabihf/debug/deps/libalsa_sys-aae2be964235592b.rlib(pcm_dmix.o): in function `snd_pcm_dmix_status':
          pcm_dmix.c:(.text+0xe0c): undefined reference to `__clock_gettime64'

I experimented with adding -lc or removing -nodefaultlibs from the generated linkline and got other errors suggesting double linking against libc.

This is the limit of my expertise, just reporting the issue in case someone else has been looking into the same thing.

0.2.0 was published to crates.io, but not to this repository. It looks like only Cargo.toml was changed in 0.2.0, but updating this repository would make things less confusing.

I'm attempting to cross-compile a project onto Raspberry Pi. It has alsa-sys as a dependency, and the linker fails when trying to link in libutil.so. For some reason, it's pulling it from /usr/lib instead of the ARM gcc library.

In target/arm-unknown-linux-gnueabihf/release/build/alsa-sys-2d409b6482724cb8/output, this option is set:

cargo:rustc-link-search=native=/usr/lib

Changing this line to the following fixes the build:

cargo:rustc-link-search=native=[pi build tools dir]/tools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/arm-linux-gnueabihf/sysroot/usr/lib/

(where [pi build tools dir] is the raspberry pi cross-compile build tools).

I'm not very familiar with how Rust's build/compile system works - is this an issue with this repository?