-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rustdoc could use some LD_LIBRARY_PATH handling cleanup #13983
Comments
Discussions with @alexcrichton lead us to think that this is not truly just a stage1 problem. As he puts it: "It is just luck that we can substitute the stage2 host binaries for target binaries." See discussion here: https://botbot.me/mozilla/rust-internals/msg/14338015/ |
note in particular: https://botbot.me/mozilla/rust-internals/msg/14339992/ |
See rust-lang#13983 and rust-lang#14000. Conflicts: src/librustc/metadata/filesearch.rs src/libstd/unstable/dynamic_lib.rs
See rust-lang#13983 and rust-lang#14000. Conflicts: src/librustc/metadata/filesearch.rs src/libstd/unstable/dynamic_lib.rs
See rust-lang#13983 and rust-lang#14000. Fix was originally authored by alexcrichton and then rebased a couple times by pnkfelix, most recently atop PR 13954.
See rust-lang#13983 and rust-lang#14000. Fix was originally authored by alexcrichton and then rebased a couple times by pnkfelix, most recently atop PR 13954. ---- Regarding the change to librustdoc/lib.rs, to do `map_err` before unwrapping a `TqskResult`: I do not understand how master is passing without this change or something like it, since `Box<Any:Send>` does not implement `Show`. (Is this something that is only a problem for the snapshot stage0 compiler?) Still, the change I have put in here (which was added as part of a rebase after alex's review) seems harmless to me to apply to rustdoc at all stages, since a call to `unwrap` is just going to `fail!` on the err case anyway.
Triage: @alexcrichton did a bunch of Rustdoc work, but I don't think that it improved this area at all. |
Triage: no change. |
Triage: not aware of any changes |
@pnkfelix it's kind of unclear to me what this issue is about. Is there some example code I could test that depends on LD_LIBRARY_PATH? |
I'm going to close this until it causes issues. |
…r=Veykril Parse const_closures syntax. Enables parsing of the syntax for `#![features(const_closures)]` introduced in [this PR](rust-lang#106004)
Spawned off of #13732.
Much like our
run-make
tests, rustdoc has a problem where it sometimes wants to be using the host'sLD_LIBRARY_PATH
to resolve dynamic library dependencies, and sometimes it wants to be using the target'sLD_LIBRARY_PATH
. (This largely comes up e.g. when running the testable code blocks embedded within rustdoc documentation blocks.)This issue is not normally exposed under normal uses of rustdoc because most people run it against a stage2 build or a rust distribution. The problem really only arises when running the documentation against stage1.
For the
run-make
tests, PR #13753 is taking the approach of feeding in two distinct environment variables (one for the host and one for the target) and relying on tooling within the makefile select the appropriate option. Presumably some similar approach would work for rustdoc.(But in the short term @pnkfelix is just going to disable the incompatible uses of rustdoc for stage1 and point them at this ticket.)
The text was updated successfully, but these errors were encountered: