[windows] Rust Bindgen does not work because libclang.dll could not be loaded

[wrenger]

Description
Rusts bindgen build tool panics because libclang.dll cannot be opened.

Area for Triage:

Rust

Question, Bug, or Feature?:

Bug

Virtual environments affected

• Ubuntu 16.04
• Ubuntu 18.04
• Ubuntu 20.04
• macOS 10.15
• macOS 11.0
• Windows Server 2016 R2
• Windows Server 2019

Image version
20210425.1

Expected behavior
It should be possible to use bindgen as (build) depenency to generate rust bindings for C APIs, similar to the linux and mac environments.

Actual behavior
Bindgen crashes because it cannot open libclang.dll:

thread 'main' panicked at 'Unable to find libclang: "the `libclang` shared library at C:\\msys64\\mingw64\\bin\\libclang.dll could not be opened: LoadLibraryExW failed"', C:\Users\runneradmin\.cargo\registry\src\jackfan.us.kg-1ecc6299db9ec823\bindgen-0.58.1\src/lib.rs:2057:31

Repro steps

1. Create a Rust Project which uses bindgen during build.
2. Create a Build Action
3. Execute the Build Action

Example Project, that uses bindgen:
https://github.com/wrenger/rust-ffi-test

Here the associated Action: https://github.com/wrenger/rust-ffi-test/actions/runs/812930118

[miketimofeev]

Hi @wrenger!
Thank you for providing repro steps, we will take a look.

[Darleev]

Hello @wrenger,
I found the issue in the rust repository with exactly the same description. The following approach was used in order to mitigate the issue:

name: Rust

on:
  workflow_dispatch: {}

env:
  CARGO_TERM_COLOR: always

jobs:
  build:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [windows-latest]

    steps:
    - name: Install LLVM and Clang # required for bindgen to work, see https://github.com/rust-lang/rust-bindgen/issues/1797
      uses: KyleMayes/install-llvm-action@32c4866ebb71e0949e8833eb49beeebed48532bd
      if: matrix.os == 'windows-latest'
      with:
        version: "11.0"
        directory: ${{ runner.temp }}/llvm
    - name: Set LIBCLANG_PATH
      run: echo "LIBCLANG_PATH=$((gcm clang).source -replace "clang.exe")" >> $env:GITHUB_ENV
      if: matrix.os == 'windows-latest'
    - uses: actions/checkout@v2
    - name: Run
      run: cargo run --verbose
      shell: cmd

I've verified that it works fine for your test repo as well. Could you please check for your main project and provide feedback?
We are looking forward to your reply.

[wrenger]

Yes ok installing llvm and clang every time is a possible solution.

However, I think because bindgen is already preinstalled in the virtual environment, it should also be functional. This is not the case if the clang and llvm libraries cannot be loaded.

Also one of the comments suggests that the clang libraries already seem be installed as part of msys. Windows is, however, unable to load them because they have dependencies to other msys libraries (libLLVM.dll ...).

[wrenger]

Ok I also found the libclang.dll in C:\msys64\mingw64\bin. Unfortunately I am not able to set the path correctly so that it can be loaded. My powershell experience is somewhat limited. I probably did something wrong...

In this action I print the contents of C:\msys64\mingw64\bin (which includes libclang) and I try to set the path correctly:
https://github.com/wrenger/rust-ffi-test/runs/2528649232?check_suite_focus=true

Could you look into that? It would be great to simply use this preinstalled clang version.

PS: I totally forgot to thank you about your fast and helpful response. Thanks 👍🏻

[Darleev]

Hello @wrenger,
I tried several ways to add and use pre-installed libclang, but it does not work properly by unknown reason. I guess, currently, the best way is to use provided solution.
In the meantime, we are investigating this case.
We'll keep you informed.

[wrenger]

Hello @Darleev,
Thank you for looking into that.

The solution of manually installing a new clang version and using it also works for my other projects. The installation adds an overhead of about 13-15s which is also not that bad.

So now this is more a matter of ease of use. As a rust developer you have to know that bindgen does not work directly on windows. Additionally, bindgen is used by many other libraries, as it generates rust bindings for c apis, so the chance is fairly high to encounter this problem.

[dsame]

@wrenger the reason of the problem is bindgen is compiled agains C:\msys64\mingw64 directory (or the path to libclang.dll is hardcoded in some other way) but cargo seems to use Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Llvm.Clang this why the .dll can not be opened despite it exists.

In order you build to pass you mast enforce cargo to use C:\msys64\mingw64\bin\clang.

This can be done this way:

    - uses: actions/checkout@v2
    - name: Run
      shell: cmd
      run: |
        set PATH=C:\msys64\mingw64\bin;%PATH%
        cargo run -v

Unfortunately we can not set mingw clang default compiler and the right way to use github actions default compiler with bindgen is to request its support team to probvive bindgen binary compiled using Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Llvm.Clang

[wrenger]

@dsame Well I tried to set the path to mingw, but without success (3ac994a).
So thank you, this solves my problem for the most part.

And I also tried to use the Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Llvm.Clang in another repo by setting the LIBCLANG_PATH to the install location of Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Llvm.Clang (inside the Visual Studio folders) as described here.
The problem is, that this clang version is a 32bit library. bindgen as 64bit executable was unable to load it.

[dsame]

@wrenger i am sorry i forget to point the success build
https://github.com/wrenger/rust-ffi-test/actions/runs/866230848
and corresponding workflow https://github.com/dsame/rust-ffi-test/blob/main/.github/workflows/rust.yml

The problem you face relates to the strange behaviour of setx /m in actions - for some reason it does not make the change permanent.

This is why i used set PATH=C:\msys64\mingw64\bin;%PATH% in the same task as cargo run -v and it works for me.

[AlenaSviridenko]

Closing this issue due to no response in a while. Please, let us know if you have any concerns or the workaround doesn't work. Thanks.

[boozook]

I suppose the problem in the path somehow 🤷🏻‍♂️