Giters

drahnr / cargo-spellcheck

Checks all your documentation for spelling and grammar mistakes with hunspell and a nlprule based checker for grammar

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Build failure due to clang

ehuss opened this issue · comments

commented

Describe the bug

I am unable to get cargo-spellcheck to build or install due to some errors with clang.

To Reproduce

cargo install cargo-spellcheck

Expected behavior

Builds and installs.

Screenshots

The error on Linux is:

error: failed to run custom build command for `clang-sys v1.4.0`

Caused by:
  process didn't exit successfully: `/home/eric/Temp/z6/cargo-spellcheck/target/release/build/clang-sys-9a070933c7cd8618/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "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: [])"', /home/eric/.cargo/registry/src/github.com-1ecc6299db9ec823/clang-sys-1.4.0/build/dynamic.rs:211:45
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The error on macOS is:

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

Caused by:
  process didn't exit successfully: `/Users/eric/Temp/z17/cargo-spellcheck/target/release/build/hunspell-sys-d062c0474d722d19/build-script-build` (signal: 6, SIGABRT: process abort signal)
  --- stderr
  dyld[53372]: Library not loaded: '@rpath/libclang.dylib'
    Referenced from: '/Users/eric/Temp/z17/cargo-spellcheck/target/release/build/hunspell-sys-d062c0474d722d19/build-script-build'
    Reason: tried: '/Users/eric/Temp/z17/cargo-spellcheck/target/release/deps/libclang.dylib' (no such file), '/Users/eric/Temp/z17/cargo-spellcheck/target/release/libclang.dylib' (no such file), '/Users/eric/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libclang.dylib' (no such file), '/Users/eric/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/libclang.dylib' (no such file), '/Users/eric/lib/libclang.dylib' (no such file), '/usr/local/lib/libclang.dylib' (no such file), '/usr/lib/libclang.dylib' (no such file)

Possible Solution

In both cases, the solution is to ensure that the default feature is enabled on hunspell-sys (in particular, this enables the bindgen/runtime feature). My workaround was to run cargo add hunspell-sys in the cargo-spellcheck project.

Please complete the following information:

commented

The difference here is, that you will create dynamically linked binary, which is not the preferred way of shipping hunspell, since different versions of hunspell exhibit different bugs. A defined version is much easier to handle.

Hence, the main question to me is, where is you clang.so?

I have a few:

# fd clang.so /usr
/usr/lib64/llvm13/lib/libclang.so.13.0.1
/usr/lib64/llvm13/lib/libclang.so.13
/usr/lib64/libclang.so.13
/usr/lib64/libclang.so.14.0.5
/usr/lib64/libclang.so
/usr/lib64/llvm12/lib/libclang.so.12
/usr/lib64/llvm11/lib/libclang.so.11.1
/usr/lib64/llvm6.0/lib/libclang.so
/usr/lib64/llvm6.0/lib/libclang.so.6.0
/usr/lib64/llvm5.0/lib/libclang.so.5
/usr/lib64/llvm5.0/lib/libclang.so
/usr/lib64/llvm5.0/lib/libclang.so.5.0
/usr/lib64/llvm6.0/lib/libclang.so.6
commented

The difference here is, that you will create dynamically linked binary

Can you say why that would be? From the binaries I created, I only see the standard system shared libraries. The bundled feature of hunspell should ensure that hunspell is linked statically.

Hence, the main question to me is, where is you clang.so?

On my Linux system I have:

/usr/lib/llvm-6.0/lib/libclang.so.1
/usr/lib/llvm-10/lib/libclang.so.1

on macOS I happen to have:

/usr/local/Cellar/llvm/15.0.6/lib/libclang.dylib
commented

By adding hunspell-sys with default features you enable bindgens runtime feature and enables dynamic linkage of clang.so - so while it links all other libs statically, libclang.so becomes dynamically linked.

So to me, the behavior should be inverted to what you see.

Did you try to follow the suggestion to set an env LIBCLANG_PATH to give the clang-sys dependency a hint?

On fedora, this is not reproducible, I run cargo install --path ./cargo-spellcheck every other week, and fedora based CI is happy too.

I'd be happy to review a PR with a sound explanation to your observations, I currently can't make sense of them.

A good startingpoint are Cargo.lock, Cargo.toml and build.rs (where it exists) of hunspell-rs, hunspell-sys, clang-sys, bindgen.

commented

I am closing for the time being, please use the pre compiled artifacts if there are issues with your distribution. I don't have capacity to test them all, I am very happy to merge PRs that would solve the issue for you.

commented

I had to sudo apt install libclang-dev on Debian to get rid of this error

commented

Did you try to follow the suggestion to set an env LIBCLANG_PATH to give the clang-sys dependency a hint?

This worked for me on MacOS.

In my case:

export LIBCLANG_PATH=/opt/homebrew/opt/llvm/lib
cargo install --locked cargo-spellcheck