Skip to content
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

Closed
pnkfelix opened this issue May 6, 2014 · 7 comments
Closed

rustdoc could use some LD_LIBRARY_PATH handling cleanup #13983

pnkfelix opened this issue May 6, 2014 · 7 comments
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@pnkfelix
Copy link
Member

pnkfelix commented May 6, 2014

Spawned off of #13732.

Much like our run-make tests, rustdoc has a problem where it sometimes wants to be using the host's LD_LIBRARY_PATH to resolve dynamic library dependencies, and sometimes it wants to be using the target's LD_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.)

@pnkfelix
Copy link
Member Author

pnkfelix commented May 7, 2014

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/

@pnkfelix
Copy link
Member Author

pnkfelix commented May 7, 2014

note in particular: https://botbot.me/mozilla/rust-internals/msg/14339992/

pnkfelix pushed a commit to pnkfelix/rust that referenced this issue May 8, 2014
See rust-lang#13983 and rust-lang#14000.

Conflicts:
	src/librustc/metadata/filesearch.rs
	src/libstd/unstable/dynamic_lib.rs
pnkfelix pushed a commit to pnkfelix/rust that referenced this issue May 15, 2014
See rust-lang#13983 and rust-lang#14000.

Conflicts:
	src/librustc/metadata/filesearch.rs
	src/libstd/unstable/dynamic_lib.rs
pnkfelix added a commit to pnkfelix/rust that referenced this issue May 15, 2014
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.
pnkfelix added a commit to pnkfelix/rust that referenced this issue May 18, 2014
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.
@steveklabnik
Copy link
Member

Triage: @alexcrichton did a bunch of Rustdoc work, but I don't think that it improved this area at all.

@steveklabnik
Copy link
Member

Triage: no change.

@steveklabnik steveklabnik added T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. and removed T-tools labels May 18, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-cleanup Category: PRs that clean code up or issues documenting cleanup. label Jul 21, 2017
@steveklabnik
Copy link
Member

Triage: not aware of any changes

@jonas-schievink jonas-schievink added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) and removed A-build labels Apr 21, 2019
@jyn514
Copy link
Member

jyn514 commented Aug 16, 2021

@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? rustdoc --test src/main.rs --target i686-unknown-linux-gnu works fine for me locally.

@ehuss ehuss removed the T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. label Jan 18, 2022
@jyn514
Copy link
Member

jyn514 commented Feb 3, 2023

I'm going to close this until it causes issues.

@jyn514 jyn514 closed this as not planned Won't fix, can't repro, duplicate, stale Feb 3, 2023
bors added a commit to rust-lang-ci/rust that referenced this issue Feb 13, 2023
…r=Veykril

Parse const_closures syntax.

Enables parsing of the syntax for `#![features(const_closures)]` introduced in [this PR](rust-lang#106004)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants