MSYS2-packages icon indicating copy to clipboard operation
MSYS2-packages copied to clipboard

Wrong location for rust stdlib

Open 500-internal-server-error opened this issue 1 month ago • 8 comments

Description / Steps to reproduce the issue

  1. pacman -S rust
  2. git clone https://github.com/mmastrac/rust-ctor.git
  3. git checkout 350d397394f91332517cf2924737b79edf9581ab (probably not necessary to pin version, but here for reproducibility)
  4. cargo test -p ctor-proc-macro --lib --locked succeeds on Linux, but fails on MSYS2.

It seems /usr/lib/rustlib/std-*.dll is not linked to /usr/bin on Windows:

$ pacman -Ql rust | grep .dll
rust /usr/bin/rustc_driver-f1b294e4060b1f94.dll
rust /usr/lib/rustlib/x86_64-pc-cygwin/lib/libstd-57fba8f4d8edb7c7.dll.a
rust /usr/lib/rustlib/x86_64-pc-cygwin/lib/std-57fba8f4d8edb7c7.dll

vs /usr/lib/rustlib/libstd-*.so to /usr/lib on Linux:

$ pacman -Ql rust | grep .so
rust /usr/lib/librustc_driver-4da335da18410923.so
rust /usr/lib/libstd-be8d7b962a3e49b4.so
rust /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-be8d7b962a3e49b4.so

For now manual symlinking/copying is a workaround, but it seems the proper fix should be in the Rust build scripts, not the distro PKGBUILD.

Expected behavior

On Linux:

    Updating crates.io index
   Compiling ctor-proc-macro v0.0.7 (/home/null/temp/test/rust-ctor/ctor-proc-macro)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 1.04s
     Running unittests src/lib.rs (target/debug/deps/ctor_proc_macro-e3285b4a78dfb8f0)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Actual behavior

On MSYS2:

   Compiling ctor-proc-macro v0.0.7 (/c/Users/User/temp/test/rust-ctor/ctor-proc-macro)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.49s
     Running unittests src/lib.rs (target/debug/deps/ctor_proc_macro-41b8744361f77cc3.exe)
C:/Users/User/temp/test/rust-ctor/target/debug/deps/ctor_proc_macro-41b8744361f77cc3.exe: error while loading shared libraries: std-57fba8f4d8edb7c7.dll: cannot open shared object file: No such file or directory
error: test failed, to rerun pass `-p ctor-proc-macro --lib`

Caused by:
  process didn't exit successfully: `/c/Users/User/temp/test/rust-ctor/target/debug/deps/ctor_proc_macro-41b8744361f77cc3.exe` (exit status: 127)
note: test exited abnormally; to see the full output pass --no-capture to the harness.

Verification

  • [x] I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

MSYS_NT-10.0-26200

Are you willing to submit a PR?

No response

For now manual symlinking/copying is a workaround, but it seems the proper fix should be in the Rust build scripts, not the distro PKGBUILD.

so it's better to open the issue in https://github.com/rust-lang/rust

ognevny avatar Nov 11 '25 17:11 ognevny

I opened #5789 for a fix. upstream will probably solve the issue in the same way

ognevny avatar Nov 11 '25 17:11 ognevny

by the way, dynamic std is pulled because of -C prefer-dynamic rustflag. this should be avoided, because that std library is needed to be available in PATH (and this requirement is not satisfied). but I can't understand why this flag is used here...

ognevny avatar Nov 11 '25 19:11 ognevny

but I can't understand why this flag is used here...

It's part of the test suite it seems, testing various permutations of configurations.

upstream will probably solve the issue in the same way

Turns out the stdlib are not supposed to be symlinked out, that's just an Arch thing. Quick test by removing the symlink and with Ubuntu shows it still works fine even without the symlink, it's just a Windows problem. So we should have the stdlib copying in our PKGBUILD.

Also, I just checked the regular mingw-w64-ucrt-x86_64-rust package, it's also lacking the stdlib in /ucrt64/bin.

Also, I just checked the regular mingw-w64-ucrt-x86_64-rust package, it's also lacking the stdlib in /ucrt64/bin.

are you sure?

/ucrt64/bin/cargo-clippy.exe
/ucrt64/bin/cargo-fmt.exe
/ucrt64/bin/cargo.exe
/ucrt64/bin/clippy-driver.exe
/ucrt64/bin/rust-gdb
/ucrt64/bin/rust-gdbgui
/ucrt64/bin/rust-lldb
/ucrt64/bin/rustc.exe
/ucrt64/bin/rustc_driver-53ef8f49cc17b831.dll
/ucrt64/bin/rustdoc.exe
/ucrt64/bin/rustfmt.exe
**/ucrt64/bin/std-b7ba0d454035f46e.dll**

ognevny avatar Nov 18 '25 10:11 ognevny

Ah oops, I must've lost track of which terminal I was in... I am juggling quite a few terminals in between working on my own projects and testing this stuff :)

upstream will probably solve the issue in the same way

Upstream does not guarantee any libs outside of $prefix/lib/rustlib, so we should fix it ourselves.

Can we add patchelf and use it?

oech3 avatar Dec 19 '25 09:12 oech3

Probably not, patchelf is, as its name suggests, for ELF binaries. There is already a PR with the fix, simply copy/link it over, matching what Arch does to get their /usr/lib/libstd-*.so.