Is there a way to statically link libunwind on x86-64-pc-windows-gnullvm?

[ongunkanat]

I have been using x86-64-pc-windows-gnullvm since it got promoted to Tier 2 with Mingw-w64 CLANG C toolchain. However sometime earlier this year I noticed that the std library also got a dependency: libunwind.dll.

I don't know what std used instead before to generate completely stand-alone executables. Now I need libunwind.dll to be shipped with them. It is not the end of the world but now I need to adjust my build pipelines to discover the path of libunwind.dll and package it.

Mingw-w64 CLANG64 actually ships the statically linked libunwind.a variant (which I can link to the C/C++ programs). Is it possible to somehow guide rustc to use a statically linked variant too? I tried changing my $CARGO_HOME/config.toml as below but since std dynamically links libunwind.dll, I think this doesn't work:

[target.x86_64-pc-windows-gnullvm]
linker = "T:/msys2/clang64/bin/clang.exe"
rustflags = [
    "-Clink-arg=T:/msys2/clang64/lib/libunwind.a"
]

The other alternative I tried:

[target.x86_64-pc-windows-gnullvm]
linker = "T:/msys2/clang64/bin/clang.exe"
rustflags = [
    "-Clink-arg=-Wl,-Bstatic",
    "-Clink-arg=-Wl,-lunwind",
    "-Clink-arg=-Wl,-Bdynamic",
]

Here are the screenshots from the DLL dependencies from the latest stable (1.87) and the version I used to use 1.83. Something has changed and now there is an external dependency on libunwind.dll:

[chrisd]

Does using crt-static work? E.g.

rustflags = ["-C", "target-feature=+crt-static"]

[ongunkanat]

It indeed does. Thanks for the suggestion! I hope that option will be kept working.

[msbroadf]

Im also having this problem. Reproduced like this: (Host is x86_64 Ubuntu 24.04.2, cargo 1.88.0)

1. Build llvm-mingw from GitHub - mstorsjo/llvm-mingw: An LLVM/Clang/LLD based mingw-w64 toolchain
2. Clone GitHub - n0-computer/dumbpipe: Unix pipes between devices
3. Add the
   [target.x86_64-pc-windows-gnullvm]
rustflags = ["-C", "target-feature=+crt-static"]
4. Build passing the path to the llvm-mingw like this:
   PATH=$PATH:/home/user/llvm-mingw/output/bin cargo build --target=x86_64-pc-windows-gnullvm --release

Running the resulting dumbpipe.exe on a windows machine requires the libunwind.dll file to be available instead of being statically linked.

[mati865]

I cannot reproduce it.

Without changing RUSTFLAGS libunwindis linked dynamically:

❯ llvm-readobj --needed-libs target/x86_64-pc-windows-gnullvm/release/dumbpipe.exe

File: target/x86_64-pc-windows-gnullvm/release/dumbpipe.exe
Format: COFF-x86-64
Arch: x86_64
AddressSize: 64bit
NeededLibraries [
  advapi32.dll
  api-ms-win-core-synch-l1-2-0.dll
  api-ms-win-crt-environment-l1-1-0.dll
  api-ms-win-crt-heap-l1-1-0.dll
  api-ms-win-crt-locale-l1-1-0.dll
  api-ms-win-crt-math-l1-1-0.dll
  api-ms-win-crt-private-l1-1-0.dll
  api-ms-win-crt-runtime-l1-1-0.dll
  api-ms-win-crt-stdio-l1-1-0.dll
  api-ms-win-crt-string-l1-1-0.dll
  bcrypt.dll
  bcryptprimitives.dll
  iphlpapi.dll
  kernel32.dll
  libunwind.dll
  ntdll.dll
  ole32.dll
  oleaut32.dll
  ws2_32.dll
]

Setting RUSTFLAGS either as environment variable or ~/.cargo/config.toml (like you did) causes libunwind to be linked statically:

❯ llvm-readobj --needed-libs target/x86_64-pc-windows-gnullvm/release/dumbpipe.exe

File: target/x86_64-pc-windows-gnullvm/release/dumbpipe.exe
Format: COFF-x86-64
Arch: x86_64
AddressSize: 64bit
NeededLibraries [
  advapi32.dll
  api-ms-win-core-synch-l1-2-0.dll
  api-ms-win-crt-environment-l1-1-0.dll
  api-ms-win-crt-heap-l1-1-0.dll
  api-ms-win-crt-locale-l1-1-0.dll
  api-ms-win-crt-math-l1-1-0.dll
  api-ms-win-crt-private-l1-1-0.dll
  api-ms-win-crt-runtime-l1-1-0.dll
  api-ms-win-crt-stdio-l1-1-0.dll
  api-ms-win-crt-string-l1-1-0.dll
  bcrypt.dll
  bcryptprimitives.dll
  iphlpapi.dll
  kernel32.dll
  ntdll.dll
  ole32.dll
  oleaut32.dll
  ws2_32.dll
]

[msbroadf]

Sorry for the noise. It seems to be working ok for me now. Not sure what changed..