Weird `cargo test` error on travis windows job

ozkriff · January 11, 2020, 10:11pm

Since Rust 1.40 release I got this error on the Windows job on Travis:

The command "cargo test --all" exited with 127.
    Finished test [unoptimized + debuginfo] target(s) in 25.78s
     Running target\debug\deps\ggwp_zgui-3b74f8e4b6c31eb3.exe
     Running target\debug\deps\ggwp_zscene-ec8c5c465c239831.exe
     Running target\debug\deps\zcomponents-1118c32f12d9d9de.exe
     Running target\debug\deps\zemeroth-87343641e1757a7b.exe
error: test failed, to rerun pass '-p zemeroth --bin zemeroth'
Caused by:
  process didn't exit successfully: `C:\Users\travis\build\ozkriff\zemeroth\target\debug\deps\zemeroth-87343641e1757a7b.exe` (exit code: 0xc0000135, STATUS_DLL_NOT_FOUND)
C:/Users/travis/.cargo/bin/cargo.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory

Has anyone seen a similar error?

cargo test seems to work fine on appveyor.

Any tips?

ozkriff · January 11, 2020, 10:40pm

Oh, this seems relevant

github.com/rust-lang/rust

Unable to run tests on dylib sub-crate in a workspace on Windows

opened 03:22PM - 03 Feb 17 UTC

closed 09:19PM - 03 Feb 17 UTC

faern

I have a workspace set up where the root crate is a normal library crate and one… of the sub-crates has crate-type `dylib`. In this setup the tests on the sub-crate can't be executed. Running the test exe (`cargo test --all`) exits with exit code: `-1073741515` Which converted becomes: `0xC0000135 = STATUS_DLL_NOT_FOUND` And I get a graphical error message stating: ``` The program can't start because test-83fa84e3d0f7a116.dll is missing from your computer. Try reinstalling the program to fix this problem. ``` And then another dialog with the same message but `test-` replaced with `std-`. The crate must both be part of the workspace and have the crate-type `dylib` to trigger this problem. # I tried this code: `root/Cargo.toml`: ```toml [package] name = "root" version = "0.1.0" [workspace] members = ["dylib"] ``` `root/dylib/Cargo.toml`: ```toml [package] name = "dylib" version = "0.1.0" [lib] crate-type = ["dylib"] ``` And then I run `cargo test --all` in the root crate or `cargo test` in the dylib crate. ## Meta Happens on both stable and nightly: `rustc 1.15.0 (10893a9a3 2017-01-19)` `rustc 1.16.0-nightly (24055d0f2 2017-01-31)` Same problem on both `x86_64-pc-windows-msvc` and `x86_64-pc-windows-gnu`. Tried both on my own machine and in appveyor. Same result.

Just for anyone else who might stumble on this. Fixing this problem is pretty easy. Just add the bin folder of your toolchain to PATH. In appveyor I did it like this in my install section:

- set PATH=%PATH%;C:\Users\appveyor\.rustup\toolchains\%RUST_VERSION%-%TARGET%\bin

UPD: Nope, export PATH=$PATH:$(rustc --print sysroot)/bin doesn't help.

UPD2: I guess, I'll use if [ $TRAVIS_OS_NAME != "windows" ]; then cargo test --all; fi as a tmp workaround for now.

system · April 10, 2020, 10:44pm

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Test failing for unknown reason help	6	697	January 12, 2023
Cargo test crash on Windows with access help	6	605	December 9, 2020
STATUS_ACCESS_VIOLATION when trying to run hello world example help	5	705	October 3, 2023
Rust update causing cargo error help	12	675	November 23, 2023
Cargo - failed to link or copy help	4	2120	January 12, 2023

Weird `cargo test` error on travis windows job

Related Topics