Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't cross-compile to armhf #38

Open
spacekookie opened this issue May 5, 2018 · 3 comments
Open

Can't cross-compile to armhf #38

spacekookie opened this issue May 5, 2018 · 3 comments

Comments

@spacekookie
Copy link

spacekookie commented May 5, 2018

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 😞

@nlfiedler
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants