test for doctest path problem #8531, and solution #12710
Conversation
|
r? @weihanglo (rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
A-build-execution
Fixes #8531. This issue was introduced by 3fd2814. Prior to that commit, the `rustdoc_process` function took other branch of the if statement being modified by this commit. The flag was previously called `is_host`, and `rustdoc` was run reporting `false`. In that commit, the flag was changed to `is_rustc_tool`, and rustdoc began reporting `true`, which resulted in the native directories added by build scripts no longer being appended to LD_LIBRARY_PATH when running doctests. This commit changes the behavior so that we are always appending the same set of paths, and the only variance is if we are cross compiling or not. An alternative would be to change rustdoc to always pass `kind: CompileKind::Host, is_rustc_tool: false`, but as rustdoc is in fact a rustc tool, that feels wrong. The commit which introduced the bug did not include context on why the flag was changed to `is_rustc_tool`, so I don't have a sense for if we should just change that flag to mean something else. While the test suite previously had an explicit test for the library path behavior of `cargo run`, it did not test this for various test forms. This commit modifies the test to ensure the behavior is consistent across `run`, normal tests, and doctests.
|
I added a test that reproduces the error initially seen in the initial tensorflow issue. I'd like to reduce that to a few files that reproduce the error so I can include it into a unit test. I'm not having luck, so if anyone wants to take a crack at it, let me know. I can get you details. I then pulled in @sgrif change from #10469 on top, and agree that the change is making the reproduced error go away. Thanks @sgrif! Additionally, I verified that the following can work as a temporary work around if you've got the shared library installed in your system. I feel like adding a build.rs should also be another path to do accomplishing the same thing, but haven't made it work yet. I'm going to go read #3366 and think on this a little longer. Next goal is slimming this test down. Anything else you want to see to close this out? |
|
I'm spinning my wheels on making a tiny test that replicates the problem. I removed the test that hits the network. We lose the exact error replication, but the test that remains ensures we have good results assuming you get libs in the right place,. @epage or @weihanglo , what else should I cover to get this closed? |
|
We're running into this for rustls. Seems like a strange bug (potentially a regression?) with potentially a straightforward fix? Cargo team, any hints on moving this forward? I could invest some time to help this along if necessary. |
There was a problem hiding this comment.
Sorry for the delay. While I think a proper solution would rustdoc delegate doctests runnning to cargo (which should be tracked in rust-lang/testing-devex-team#5), we should try moving this forwards, or at least have a conclusion what to do next. Will put this in the agenda of the triage meeting.
What does this PR try to resolve?
Fixes issue #8531 , wherein we have doctests that fail with a shared library error.
The issue seems painful enough that folks are changing their code to avoid this bug. We need a solution.
How should we test and review this PR?
I added a tentative test that reproduces the problem, and reusing #10469, show that solution works.
The repair in question is small. Toggle it off and the test fails with shared library problems.