rust: update to 1.85.0

[ognevny]

• remove backports
• do not package rust-src for i686
• (taken from arch) apply --long option to zstd for pkg tarball
• strip wasm .rlib files manually

config change:

• unconditionally enable control flow guard. -C control-flow-guard is ignored for non-gnullvm targets, so for non-clang environments it does nothing
• enable crt-static explicitly: rust: update to 1.85.0 #23426 (comment)

[ognevny]

IIUC after this change libunwind will be linked dynamically for gnullvm targets

@mati865 am I correct?

[mati865]

Yes, but this was already present in 1.84.0.

[ognevny]

Yes, but this was already present in 1.84.0.

in relevant PR rustbot put it into 1.85.0 milestone

[ognevny]

in relevant PR rustbot put it into 1.85.0 milestone

yeah, now some executables now link libunwind.dll

  /clang64/bin/cargo-fmt.exe:
  	libunwind.dll => D:\M\msys64\clang64\bin\libunwind.dll (0x0000019ceb470000)
  /clang64/bin/cargo.exe:
  	libunwind.dll => D:\M\msys64\clang64\bin\libunwind.dll (0x000001aa355d0000)

I'll open a separate PR for rebuilding all rust-based packages with

if [[ ${MINGW_PACKAGE_PREFIX} == *-clang-* ]]; then
  depends=("${MINGW_PACKAGE_PREFIX}-libunwind")
fi

being put where needed

[mati865]

Yes, but this was already present in 1.84.0.

in relevant PR rustbot put it into 1.85.0 milestone

Ah, you are right. I had looked at the milestone at rust-lang/rust#132965

[mati865]

I'll open a separate PR for rebuilding all rust-based packages with

if [[ ${MINGW_PACKAGE_PREFIX} == *-clang-* ]]; then
  depends=("${MINGW_PACKAGE_PREFIX}-libunwind")
fi

being put where needed

There is no specific need to rebuild them. Both std and unwinder are linked statically so they won't break.

Regarding libunwind, it provides *-gcc-libs package, so anything that depends on *-gcc-libs will pull libunwind in CLANG* envs:

MINGW-packages/mingw-w64-libc++/PKGBUILD

Line 155 in 0dd137f

depends=($( (( _clangprefix )) || echo "${MINGW_PACKAGE_PREFIX}-gcc-libs"))

[ognevny]

Regarding libunwind, it provides *-gcc-libs package, so anything that depends on *-gcc-libs will pull libunwind in CLANG* envs:

I meant that majority of rust-based packages here doesn't depend on any library. and libunwind.dll becomes the only dll linked (and for CLANG*) only. rust itself will always ship libunwind, so it'll be always linked

[ognevny]

and also libc++ provides gcc-libs, libunwind only depends on it in CLANG* environments. in non-clang envs libunwind is not a dependency of gcc-libs

[mati865]

and also libc++ provides gcc-libs, libunwind only depends on it in CLANG* environments. in non-clang envs libunwind is not a dependency of gcc-libs

Right. What I meant to tell is all packages using Rust as the compiler depend or libgcc_s.dll in GNU envs and soon libunwind.dll in LLVM envs. So adding libunwind as the dependency seems weird, since they don't depend on gcc-libs in GNU envs.

[ognevny]

Right. What I meant to tell is all packages using Rust as the compiler depend or libgcc_s.dll in GNU envs.

libgcc_s is linked statically IIRC

So adding libunwind as the dependency seems weird, since they don't depend on gcc-libs in GNU envs.

that's why I will put libunwind conditionally

[mati865]

Right. What I meant to tell is all packages using Rust as the compiler depend or libgcc_s.dll in GNU envs.

libgcc_s is linked statically IIRC

No, there are two libraries: libgcc_eh.a and libgcc_s.dll.a. First one is static, the other one is an import library for shared library.
Rust, just like other compiler links shared library, so resulting binaries depend on it.

[ognevny]

libgcc_s is linked statically IIRC

windows-gnu should have crt_static_allow_dylib: true like windows-gnullvm, right?

[ognevny]

No, there are two libraries: libgcc_eh.a and libgcc_s.dll.a. First one is static, the other one is an import library for shared library. Rust, just like other compiler links shared library, so resulting binaries depend on it.

I've just checked lsd package. the binary depends only on windows libs, but none from msys2

$ ntldd -R /ucrt64/bin/lsd | rg msys
<empty>

[mati865]

Ah, I forgot about late_link_args_dynamic and late_link_args_static. So, binaries created for windows-gnu will use static unwinder if they don't depend on other shared libraries, like in lsd's case. I don't want to reboot into Windows right now but I'm confident if you inspect uv package or any other package depending on any DLL (regardless if the DLL needs unwinder or not), ntldd will show libgcc_s.

windows-gnullvm can be controlled whether to link static or shared unwind library with crt-static: https://doc.rust-lang.org/reference/linkage.html#r-link.crt.crt-static
Either by passing it via RUSTFLAGS or command line.

windows-gnu should have crt_static_allow_dylib: true like windows-gnullvm, right?

I cannot without bigger changes, right that would clash with its logic for determining which unwind library to link.

---

EDIT: Ideally both targets would share the same logic (and be controllable via crt-static), but that won't happen soon.

[mati865]

Also, there is https://github.com/rust-lang/rust/blob/28b83ee59698ae069f5355b8e03f976406f410f5/config.example.toml#L882 that restores the previous behaviour.

[ognevny]

but, why not having dynamic crt here (even when it's only for CLANG environments)? it's not hard to maintain the requirement of having libunwind installed to use rust-based binaries

[mati865]

Only to avoid having to deal with PKGBUILDs updates.

[ognevny]

I understand you...

so I'll fill an issue upstream for crt-static support for windows-gnu tomorrow (you can actually do this too). also I'll push that config change you mentioned. in some cases I'll use -crt-static if other dlls are linked

[ognevny]

looks like one of the removed backport will come back again: rust-lang/rust#137460