Wrong location for rust stdlib
Description / Steps to reproduce the issue
pacman -S rustgit clone https://github.com/mmastrac/rust-ctor.gitgit checkout 350d397394f91332517cf2924737b79edf9581ab(probably not necessary to pin version, but here for reproducibility)cargo test -p ctor-proc-macro --lib --lockedsucceeds 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
I opened #5789 for a fix. upstream will probably solve the issue in the same way
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...
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**
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?
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.