cargo

cargo copied to clipboard

Problem cargo test --doc doesn't appear to be loading the same shared libraries as cargo test --lib in 1.45

Steps

1. Clone https://github.com/tensorflow/rust
2. Set Rust to 1.44
3. Note that both cargo test --doc and cargo test --lib pass
4. Set Rust to 1.45
5. Note that cargo test --lib passes but cargo test --doc fails with error while loading shared libraries: libtensorflow.so.1: cannot open shared object file: No such file or directory

Notes

Output of cargo version: cargo 1.44.0 (05d080faa 2020-05-06) or cargo 1.45.0 (744bd1fbb 2020-06-15)

Running on Ubuntu 20.04 LTS.

For what it's worth, I'm seeing the same issue running doctests against my library that uses SDL2 (https://github.com/Rust-SDL2/rust-sdl2). cargo +1.44.0 test --doc works.

Same problem with any OS + rust1.48+, but not with rust1.42. cargo test --doc with shared lib seems to be broken.

Using git bisect, I narrowed down to 3fd28143de72d2d0e63186273d68aa890d8297e7 being the breaking commit.

This is still broken on 1.58

This issue is known for almost 3 years, could you give us a timeline when a fix will come? Not knowing about this I just wasted hours trying to find out why my doc tests fail :(

Is there a workaround for this issue?

Update: I found that I can workaround this by prefixing the command with LD_LIBRARY_PATH indicating the location of the shared libraries: LD_LIBRARY_PATH=... cargo test --doc

@adamcrume do you have any clue what might have caused this bug? Is @alexcrichton still around? Iirc he was stepping down from several Rust projects, but not cargo.

I don't know what specifically in 3fd28143de72d2d0e63186273d68aa890d8297e7 caused this. I'm not familiar with the cargo codebase.

We appreciate Alex efforts on Cargo and Alex has already retired from the Cargo Team.^1

There was a previous attempt https://github.com/rust-lang/cargo/pull/10469 and concerns were listed https://github.com/rust-lang/cargo/pull/10469#issuecomment-1079503079. Feel free to pick it up and continue.

@weihanglo with all due respect, the concerns you linked do not point towards a, obvious, clear path forward how this issue should be remediated. I do understand you rely on others to help you fix bugs, but a community can do that with reasonable efficacy only if it is crystal clear how things should work. The concerns you listed are referenced and thought through, but they don't enable outsiders to grasp how you'd want things to be done.

This bug is a problem for the Rust ecosystem. I'd love to recommend Rust more strongly in industrial projects, but this is one of the reasons why I cannot. The cargo team has broken the test coverage for all crates that include native dylibs, and some crates have responded by disabling their doctests with no_run, other crates have stopped efforts to link against included native libraries with a guaranteed matching version, and instead rely on package managers installing a more or less matching version, thus causing undefined behavior. Cargo should not ignore bugs that incentivize maintainers to reduce test coverage or cause undefined behaviour for years.

@ehuss I hate to be nagging, but at which point in time will the cargo team fix this issue, if no volunteers are able to address it in a way you'd accept it? How do you select which bug fixes are scheduled for a new cargo release?

Looks as though no one is looking at this. I'm new to the code, but this seems approachable to me. I'll take a wack if it's really open.