dll load failure running a cargo test on msvc 64 bit

[mcgoo]

This is against commit 7cfeec1 which is a bors commit that succeeded in appveyor.

C:\Users\jim\src\cargo>cargo test --test test test_dylib
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running target\debug\deps\test-77435f12f6831dd7.exe

running 1 test
test test_dylib ... FAILED

failures:

---- test_dylib stdout ----
        running `C:\Users\jim\src\cargo\target\debug\cargo.exe test`
thread 'test_dylib' panicked at '
Expected: execs
    but: exited with exit code: 3221225781
--- stdout

--- stderr
   Compiling bar v0.0.1 (file:///C:/Users/jim/src/cargo/target/cit/t0/foo/bar)
   Compiling foo v0.0.1 (file:///C:/Users/jim/src/cargo/target/cit/t0/foo)
    Finished dev [unoptimized + debuginfo] target(s) in 1.8 secs
     Running target\debug\deps\foo-a0c0f1a4a973ba06.exe
error: test failed, to rerun pass '--lib'
', C:\Users\jim\.cargo\registry\src\github.com-1ecc6299db9ec823\hamcrest-0.1.1\src\core.rs:31
stack backtrace:
   0: std::sys_common::backtrace::_print
             at C:\projects\rust\src\libstd\sys_common\backtrace.rs:94
   1: std::panicking::default_hook::{{closure}}
             at C:\projects\rust\src\libstd\panicking.rs:354
   2: std::panicking::default_hook
             at C:\projects\rust\src\libstd\panicking.rs:365
   3: std::panicking::rust_panic_with_hook
             at C:\projects\rust\src\libstd\panicking.rs:549
   4: std::panicking::begin_panic<collections::string::String>
             at C:\projects\rust\src\libstd\panicking.rs:511
   5: std::panicking::begin_panic_fmt
             at C:\projects\rust\src\libstd\panicking.rs:495
   6: hamcrest::core::assert_that<cargo::util::process_builder::ProcessBuilder,cargotest::support::Execs>
             at .\<panic macros>:8
   7: test::test_dylib
             at .\tests\test.rs:1115
   8: test::{{impl}}::call_box<(),closure>
             at C:\projects\rust\src\libtest\lib.rs:139
   9: panic_unwind::__rust_maybe_catch_panic
             at C:\projects\rust\src\libpanic_unwind\lib.rs:98
  10: std::panicking::try::do_call<std::panic::AssertUnwindSafe<closure>,()>
             at C:\projects\rust\src\libstd\panicking.rs:450
  11: panic_unwind::__rust_maybe_catch_panic
             at C:\projects\rust\src\libpanic_unwind\lib.rs:98
  12: alloc::boxed::{{impl}}::call_box<(),closure>
             at C:\projects\rust\src\liballoc\boxed.rs:648
  13: std::sys::imp::thread::{{impl}}::new::thread_start
             at C:\projects\rust\src\libstd\sys\windows\thread.rs:50
  14: BaseThreadInitThunk


failures:
    test_dylib

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured

error: test failed, to rerun pass '--test test'

[mcgoo]

Here is the error from the DLL not found popup.

foo-a0c0f1[..].exe System Error
code execution cannot proceed... test-9de4a[..].dll was not found.
Then the same for std-26aaf[..].dll

target/cit contains :-

.
└── t0
├── foo
│   ├── bar
│   │   ├── Cargo.toml
│   │   └── src
│   │   └── lib.rs
│   ├── Cargo.lock
│   ├── Cargo.toml
│   ├── src
│   │   └── lib.rs
│   ├── target
│   │   └── debug
│   │   ├── build
│   │   ├── deps
│   │   │   ├── bar.dll
│   │   │   ├── bar.dll.exp
│   │   │   ├── bar.dll.lib
│   │   │   ├── bar.pdb
│   │   │   ├── foo-a0c0f1a4a973ba06.exe
│   │   │   ├── foo-a0c0f1a4a973ba06.pdb
│   │   │   ├── foo.dll
│   │   │   ├── foo.dll.exp
│   │   │   ├── foo.dll.lib
│   │   │   ├── foo.pdb
│   │   │   ├── test-6c16c0530b1c07ff.exe
│   │   │   └── test-6c16c0530b1c07ff.pdb
│   │   ├── examples
│   │   ├── foo-a0c0f1a4a973ba06.d
│   │   ├── foo-a0c0f1a4a973ba06.exe
│   │   ├── foo.dll
│   │   ├── incremental
│   │   ├── native
│   │   ├── test-6c16c0530b1c07ff.d
│   │   └── test-6c16c0530b1c07ff.exe
│   └── tests
│   └── test.rs
└── home

[mcgoo]

other tests that fail: plugins, and bench_dylib.

The machine is a pretty new install of Windows 10 1703, with Visual Studio 2015.3, Visual Studio 2017 and the Windows 10 SDK.

It does not seem sensitive to the version of Rust but I tried the version that the CI server is using which is nightly 2017-03-03.

I blew away ~/.cargo, ~/.multirust and ~/.rustup before installing with rustup-init-exe (1.2.0)

rustup-init 1.2.0 (70faf07 2017-04-08)
rustc 1.17.0-nightly (c0b7112ba 2017-03-02)
cargo 0.18.0-nightly (19ea423 2017-03-02)

[mcgoo]

also fails on another machine running Windows 10 Home 1703.
Fails as far back as 2016-09-01 e4b4471 Auto merge of #3065 - mbrock:master, r=alexcrichton

[mcgoo]

The test-xxxx.dll that it can't find is the one in rustlib\x86_64-pc-windows-msvc\lib.

This is the test generated by cargo's test_dylib test: foo.zip. Unpack, cargo test to see the failure, dll not found popup in my case. (or not, since it apparently works on the CI server.)

It works for me if I add C:\Users\jim.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib to my path, but fails otherwise.

[alexcrichton]

I believe this error is fixed on Unix via this code although I have no idea how it's working elsewhere today...

Can you gist the output with -v in Cargo's output (just to see compiler flags)

[mcgoo]

https://gist.github.com/mcgoo/ff1b002243eae18becb41a3677d72473

[mcgoo]

That code (tests/cargotest) is just for cargo testing cargo, right? Because this is a cargo testing anything issue too. (It seems like that foo example above should work standalone, not just as part of the cargo testsuite?)

Does something already know the rustlib dir inside cargo itself? rustc --print sysroot gets most of the way.

The dylib search path is getting set here. Should it include the rustlib dir too?

[alexcrichton]

Ok so -C prefer-dynamic is being passed which confirms my suspicions. Yes this is only for testing Cargo but I'd prefer to figure out what's going on first. This works on AppVeyor for some reason and isn't working locally, so there's some difference between the two environments.

As I typed this out I remembered that we pin to an old version of rustup due to #3394.

So given that I think we should (a) fix Cargo, probably through those lines of code that I linked above (I had forgotten about before) and (b) not worry about Cargo in the ecosystem. In general it's up to developers to manage library lookup paths wrt local toolchains.

Would you be interested in patching up the code mentioned previously?

[mcgoo]

I'm pretty busy and this is all a major digression from what I am actually trying to get done so I'm not sure.

That said - can you clarify something for me? It looks like the unixoids all get the lib directory above rustlib/<triple>/lib added to their LD_LIBRARY_PATH. I'm not sure how that actually works - is there an rpath (or similar mechanism) causing the loader to look in rustlib/<triple>/lib under each LD_LIBRARY_PATH entry? It looks wrong to me but it seems to work - is it correct?

On Windows, to the best of my knowledge you need the exact directory to look in, so you need the correct triple in order to generate the right path. Do you know where I can get the triple?

Thanks

[alexcrichton]

Oh that's fine, no worries!

Nah on Unix there's no rpath entries into the rustlib dir, instead it's intended that code is run against the libraries the compiler runs with, those in lib in the sysroot.

The correct triple can be extracted from rustc --version --verbose I believe.

[mcgoo]

Thanks for helping me work through this. Closing as a dupe of #3394