windows-gnullvm: Avoid linking to libunwind statically

[kleisauke]

Avoid linking against the static variant of libunwind, which is not always available. Instead, prefer to use the unwind library from the toolchain, which the linker will automatically include, depending on what's available.

[rustbot]

r? @fmease

rustbot has assigned @fmease.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Failed to set assignee to mati865: invalid assignee

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

[mati865]

I don't see how crt-static would affect libunwind linkage with these changes. I think it would require special handling like here:

rust/library/unwind/src/lib.rs

Lines 52 to 54 in 878c8a2

	#[link(name = "unwind", kind = "static", modifiers = "-bundle", cfg(target_feature = "crt-static"))]
	#[link(name = "unwind", cfg(not(target_feature = "crt-static")))]
	extern "C" {}

I'll test it during the weekend.

Also I think it might be the best to just build the unwinder during Rust build and always link it statically like here:

rust/library/unwind/src/lib.rs

Line 49 in 878c8a2

#[link(name = "unwind", kind = "static", modifiers = "-bundle")]

[kleisauke]

Ah, you're right, it looks like that only applies to Linux and Fuchsia targets.

rust/library/unwind/Cargo.toml

Lines 31 to 34 in 6cbf092

	# Only applies for Linux and Fuchsia targets
	# If crt-static is enabled, static link to `libunwind.a` provided by system
	# If crt-static is disabled, dynamic link to `libunwind.so` provided by system
	system-llvm-libunwind = []

I just clarified my commit message.

FWIW, here's a Dockerfile to reproduce this:

Details

# Build with:
# docker build -t llvm-mingw .
FROM docker.io/mstorsjo/llvm-mingw:latest

# Supported architectures: x86_64, i686, aarch64 and armv7
ARG ARCH=x86_64

# Path settings
ENV RUSTUP_HOME="/usr/local/rustup" \
    CARGO_HOME="/usr/local/cargo" \
    PATH="/usr/local/cargo/bin:$PATH"

# Install curl
RUN apt-get update -qq && \
    apt-get install -qqy --no-install-recommends curl && \
    apt-get clean -y && \
    rm -rf /var/lib/apt/lists/*

# Install Rust
RUN curl https://sh.rustup.rs -sSf | sh -s -- -y \
      --no-modify-path \
      --profile minimal \
      --target $ARCH-pc-windows-gnullvm \
      --default-toolchain nightly \
      --component rust-src

WORKDIR /build

# Special flags for Rust
ENV CARGO_PROFILE_RELEASE_DEBUG=false \
    CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1 \
    CARGO_PROFILE_RELEASE_INCREMENTAL=false \
    CARGO_PROFILE_RELEASE_LTO=true \
    CARGO_PROFILE_RELEASE_OPT_LEVEL=z \
    CARGO_PROFILE_RELEASE_PANIC=abort

RUN rm /opt/llvm-mingw/$ARCH-w64-mingw32/lib/libunwind.a

RUN cargo new foo --lib --vcs none && \
    cd foo && \
    echo "pub fn foo() {}" > src/lib.rs && \
    cargo rustc --release --crate-type=cdylib --target=$ARCH-pc-windows-gnullvm -Zbuild-std=std,panic_abort && \
    llvm-readobj --coff-imports target/$ARCH-pc-windows-gnullvm/release/foo.dll

[fmease]

Not my area of expertise
r? compiler

[nnethercote]

r? @petrochenkov
cc @mati865

[mati865]

The problem linking dynamic libunwind is the need of shipping libunwind together with the library/binary. I'll try if I can get crt-static feature to work or build libunwind together with std.

[kleisauke]

Ah, I see. LLVM just uses -lunwind, so it will link against the static libunwind.a variant when libunwind.dll{,.a} is not available.
https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/clang/lib/Driver/ToolChains/CommonArgs.cpp#L1829-L1831

If you pass -Clink-args=-static-libgcc, it will forcibly link against libunwind.a, but this is a bit odd from a Rust point of view. I'll close.

[mati865]

Opened #122003 that builds libunwind for these targets so we become independent of host toolchain when it comes to libunwind. Did some testing during Sunday and it seems to work fine but I'll try it with your Dockerfile using toolchain built the official way.