nlfiedler / magick-rust

Rust bindings for ImageMagick
https://crates.io/crates/magick_rust
Apache License 2.0
254 stars 68 forks source link

Can't cross-compile to armhf #38

Open spacekookie opened 6 years ago

spacekookie commented 6 years ago

I'm using a cargo-cross setup to compile a project that uses magick-rust in a docker container. But while the other -sys crates can be built, magick-rust fails with this error:

error: failed to run custom build command for `magick_rust v0.8.0`
process didn't exit successfully: `/target/debug/build/magick_rust-d97c639e6e935b43/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 of [\'libclang.so\', \'libclang.so.*\', 
        \'libclang-*.so\'], set the LIBCLANG_PATH environment variable to a path where one of these files 
        can be found (skipped: [(/usr/lib/arm-linux-gnueabihf/libclang-3.8.so: invalid ELF class (32-bit)),
        (/usr/lib/llvm-3.8/lib/libclang-3.8.1.so: invalid ELF class (32-bit))])"', 
        libcore/result.rs:945:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Not really sure what to do here? The library it needs is installed, even for armhf. But I think magick-rust doesn't realise this? Because it just skips the library it should link against :disappointed:

nlfiedler commented 6 years ago

This crate does not have a direct dependency on clang. I believe that is coming from the combination of rust-bindgen and the Rust compiler. When I've run into the problem of rustc not knowing where the clang libraries are located, I set the LIBCLANG_PATH environment variable. When building this crate on FreeBSD, for instance, I set it to /usr/local/llvm-devel/lib, which seems to be where the clang-devel package installs the libs. If you have suggestions for how I could make this easier, I'd be happy to hear them.

spacekookie commented 6 years ago

Ah, so I manually set LIBCLANG_PATH to /usr/lib/x86_64-linux/ to force clang to use the x86 variant that's required for it to run on my machine/ travis infrastructure. And that largely fixed the issue I've had above.

However now I have a new issue. It fails to compile...something...further down the line:

/usr/include/stdio.h:33:11: fatal error: 'stddef.h' file not found
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ()', libcore/result.rs:945:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Any ideas?

nlfiedler commented 6 years ago

To produce the Rust bindings for ImageMagick, this crate uses the build.rs "feature" to invoke rust-bindgen. Something is looking for that header file, but I don't know what that would be. Your best bet is to add println! statements to the build.rs at strategic locations; output from this code ends up in an output file in the target directory. Maybe print the values for the include path, or something along those lines. It's been a long time since I've touched this file, and it's changed a lot since then, so I don't know all the details any more.