Closed ehuss closed 1 year ago
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
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
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
.
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.
I had to sudo apt install libclang-dev
on Debian to get rid of this error
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
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:
The error on macOS is:
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 runcargo add hunspell-sys
in the cargo-spellcheck project.Please complete the following information:
cargo install cargo-spellcheck
or cloned from https://github.com/drahnr/cargo-spellcheck.git