Cannot find libclang with docker rust image and 0.42 bindgen

[nlfiedler]

Using this repo (https://github.com/nlfiedler/magick-rust/) to compile bindings for ImageMagick has been working pretty well for a while. Was using bindgen 0.29, then tried to update to 0.42 today. That was relatively painless and builds fine on macOS, but the build fails using the latest official Docker image for rust (https://hub.docker.com/_/rust/). Versions of bindgen between 0.32 and 0.41 result in voluminous (different) compiler errors, while only 0.42 errors out as seen here:

error: failed to run custom build command for `magick_rust v0.10.0 (file:///src)`
process didn't exit successfully: `/src/target/debug/build/magick_rust-99bb30e553cee594/build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-env-changed=IMAGE_MAGICK_LIB_DIRS
cargo:rerun-if-env-changed=IMAGE_MAGICK_DIR
cargo:rustc-link-search=native=/usr/local/lib
cargo:rerun-if-env-changed=IMAGE_MAGICK_INCLUDE_DIRS
cargo:rerun-if-env-changed=IMAGE_MAGICK_DIR
cargo:include=/usr/local/include/ImageMagick-7
cargo:rerun-if-env-changed=IMAGE_MAGICK_LIBS
cargo:rerun-if-env-changed=IMAGE_MAGICK_STATIC
cargo:rustc-link-lib=dylib=MagickWand-7.Q16HDRI
cargo:rustc-link-lib=dylib=MagickCore-7.Q16HDRI

--- stderr
thread 'main' panicked at 'Unable to find libclang: "couldn\'t find any valid shared libraries matching: [\'libclang.so\', \'libclang-*.so\'], set the `LIBCLANG_PATH` environment variable to a path where one of these files can be found (invalid: [])"', libcore/result.rs:945:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

For now, sticking with bindgen 0.31 as that is working without any issue.

Just to be absolutely clear, the only thing changing is the version of bindgen in the project's Cargo.toml; the docker image is the same. Also note that versions 0.29, 0.31, and 0.42 all build fine on macOS. This appears to be specific to 0.42 and the Linux-based docker image.

[auscompgeek]

Uh, bindgen 0.42 hasn't been released yet, right? I'm not going mad, am I?

[emilio]

It has, I did that after #1410. The only difference between bindgen 0.41 and 0.42 in that test is the clang-sys version.

The new clang-sys version includes KyleMayes/clang-sys@cc11523, which is likely to be the culprit, cc @KyleMayes.

[emilio]

Closing as "not a bindgen bug", filed KyleMayes/clang-sys#83 for this. If this is very severe we could consider revert the clang-sys upgrade for now, just let me know.

[emilio]

Uh, bindgen 0.42 hasn't been released yet, right? I'm not going mad, am I?

I just checked and I forgot to tag it, should be fixed now, sorry :)

[KyleMayes]

This one is on me...

I removed searching for versioned libraries matching the pattern libclang.so.* (e.g., libclang.so.1) in v0.24.0 because I thought that adding it originally must have been a mistake because ld can't link to libraries with filenames like libclang.so.1.

However:

a) On BSD distributions, dynamic libraries are versioned like this: libclang.so.7.0 (fixed in v0.25.0)
b) On Linux distributions, while ld can't link to libclang.so.1, libloading can (fixed in v0.26.0)

I have published v0.26.0 which enables linking to versioned libraries matching the pattern libclang.so.* on Linux only when the runtime feature is enabled.

I have tested this version with the magick-rust Docker container and it works (though there is an error in the generated Rust code, but that shouldn't have anything to do with clang-sys).

[emilio]

Thanks for the quick turnaround! I updated it in #1415.

[siscia]

Gentlemen,

in my test, I still get this same error.

Using docker as build environment I cannot get bindgen to work.

The project I am trying to build is: github.com/redbeardlab/redisql
While the image I am using is: siscia/x86_64-unknown-linux-gnu2.14:1-error-bindgen

I am trying to build the image using cross

Cheers,
Simone

[siscia]

Update, the problem seems to be cross and not bindgen.