libclang detection fails on GitHub Action

[saschanaz]

Background: rust-lang/rust-bindgen#1797

I had to add this step:

      - name: Set LIBCLANG_PATH
        run: echo "LIBCLANG_PATH=$((gcm clang).source -replace "clang.exe")" >> $env:GITHUB_ENV

... per the following line:

clang-sys/build/dynamic.rs

Line 149 in ddd3af5

for (directory, filename) in common::search_libclang_directories(&files, "LIBCLANG_PATH") {

It seems this is only problematic in GitHub Action, not sure why. It's not a problem in my Windows machine without that environment variable.

My current script: https://github.com/saschanaz/jxl-winthumb/blob/2fc12d454163c7096158f93b712ef9f51b6f1f4b/.github/workflows/ci.yml

[BlackHoleFox]

This is probably because visual studio installs clang under C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\VC\\Tools\\Llvm\\bin. The path isn't on clang-sys's search list.

Is this where your clang is locally or are you using the distribution from LLVM which is stored at C:\\LLVM\\?

[KyleMayes]

I added the Visual Studio LLVM component directory to the search paths as part of the now released v1.1.0.

I downloaded the Visual Studio LLVM component on my Windows machine and clang-sys found that libclang so hopefully this should remove the need to manually set LIBCLANG_PATH for users relying on the VS LLVM component.

[saschanaz]

Well, my script installs LLVM by KyleMayes/install-llvm-action (your GH Action script 😉) so I don't think it's about Visual Studio.

[KyleMayes]

Yes, I see that now.

I tunnel visioned on the mention of VS in a previous comment.
I think the solution is just to set LIBCLANG_PATH like I do in the CI for this crate.
It probably shouldn't be necessary, but 🤷‍♂️ .

[saschanaz]

Could it try guessing by the global clang path, which is what my step does? 👀

[KyleMayes]

clang-sys should be finding it already because install-llvm-action adds the installed directory to LD_LIBRARY_PATH and clang-sys searches LD_LIBRARY_PATH.

Why this isn't working I don't know.

I'll reopen the issue since it is a bug that should be fixed but I can't guarantee I'll get around to investigating it in a timely fashion.

[trevyn]

This also appears to be a problem on Azure Pipelines: mimblewimble/grin#3596 (comment)

[KyleMayes]

I've partially fixed this problem (for dynamic linking but not runtime linking) in 1.2.0:

• First, I fixed my install-llvm-action GitHub action to use the platform appropriate path delimiter (I was using : always but Windows uses ;) when updating LD_LIBRARY_PATH with the path to the LLVM/Clang binaries: KyleMayes/install-llvm-action@4609a7b

• Second, I fixed this crate to properly split the paths in LD_LIBRARY_PATH using the platform appropriate path delimiter (same as before, using : when Windows uses ;) when searching for Clang binaries: 84b17df

I removed setting the environment variables in the CI YAML for this crate as a demonstration of clang-sys being able to find the Clang binaries when linking dynamically after these changes. However, as reported in rust-lang/rust-bindgen#1797, clang-sys still attempts to link to an invalid MinGW libclang.so instance when linking at runtime.

Not sure what's going on there, I'll try to take another crack at it this weekend.

[perqin]

I added the Visual Studio LLVM component directory to the search paths as part of the now released v1.1.0.

I downloaded the Visual Studio LLVM component on my Windows machine and clang-sys found that libclang so hopefully this should remove the need to manually set LIBCLANG_PATH for users relying on the VS LLVM component.

On my Windows machine, the LLVM is by default installed into C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\Llvm. Should we add this path too? I've googled a bit, but didn't find any documentation provided by Microsoft telling the standard location in where the bundled LLVM is installed.

[KyleMayes]

It no longer seems necessary to set LIBCLANG_PATH in GitHub actions that use Windows.

I was able to remove the last clang-sys environment variable from this repository's CI action and it worked just fine (609d1c1).

I'm going to close but if someone has a similar issue please open a new issue.