-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Riscv64linux Test fixes #80839
Riscv64linux Test fixes #80839
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
25ccd2e
to
00930aa
Compare
Ping from triage: |
@JohnCSimon ready for review |
@Mark-Simulacrum @nagisa ping |
For linkcheck, I'm sort of still uncertain - I would expect us to build docs for both rustc and cargo (for example) for a given platform, not just one of them, and as such for links to work as expected. Does one of them perhaps need a host-only annotation? |
Ok, so after looking into the code a bit, it sounds like the problem is that rustc and rustdoc internal documentation (i.e., rustdoc run on those crates) is built for host platforms only, but other documentation (e.g., cargo, reference, etc. books) are built for targets too. I don't think disabling linkcheck is the right fix - you have genuinely broken links in the generated docs. Rather, it seems like the problem is that building the default documentation (i.e.,
This would quite clearly lead to link failures from the host to the target. I can see several strategies for fixing this:
I'm personally not even sure that we should do any of these 3, but of them, I feel like option 2 is the most appealing from a "building working documentation" policy -- it is also unfortunately going to be very error prone over time if we're not testing this kind of configuration as links get added. Option 1 is definitely the easiest -- I'd be ok landing it with a panic instead of silently passing, and recommending that folks that explicitly are OK with broken documentation pass --exclude src/tools/linkchecker to their x.py test invocation. Do you think that's reasonable? |
@Mark-Simulacrum thanks for taking a look. The python3 ../x.py --stage 2 test --target riscv64gc-unknown-linux-gnu Are you saying the intent of that is unclear? What should it be? It looks like armhf-gnu uses Thanks for the possible solutions to the general problem. I'll see what I can get working this weekend. |
Yeah, currently the test invocation is testing sort of an unusual combination- the host is specified implicitly as the build triple, but the target list doesn't include the host. That's at least plausibly not intended. It's possible just specifying host to be empty (i.e. only check the target bits, not the compiler for example) is what's actually intended. |
00930aa
to
5419f82
Compare
I've updated the MR adding Thanks for your help @Mark-Simulacrum |
This comment has been minimized.
This comment has been minimized.
5419f82
to
b71573b
Compare
This comment has been minimized.
This comment has been minimized.
The most recent failure was because the x64_64-gnu-llvm-9 Dockerfile also left the host to implicitly be different to the target (in one instance, other invocations do specify I've checked the other Dockerfiles for the same issue and they look okay. |
Ping from triage: @tblah do you want a new review? If so, please post a comment including |
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
☔ The latest upstream changes (presumably #83387) made this pull request unmergeable. Please resolve the merge conflicts. |
Resolves rust-lang#78911 The target's linker was used but rustc wasn't told to build for that target (instead defaulting to the host). This led to the host instead of the target getting tested and to the linker getting inappropriate arguments.
The test assumes it can run target binaries on the host. This not true for riscv64 CI (or for other platforms using remote-test-server).
When we cross compile, some things (and their documentation) are built for the host (e.g. rustc), while others (and their documentation) are built for the target. This generated documentation will have broken links between documentation for different platforms e.g. between rustc and cargo.
The tests issue-36710 and incr-prev-body-beyond-eof were changed in a previous commit so that the correct target was passed to rustc (previously rustc was building for the host not for the specific target). Since that change it turns out that these platforms never worked (they only appeared to work because rustc was actually building for the host architecture). The wasm architectures fall over trying to build the C++ file in issue-36710. They look for clang (which isn't installed in the test-various docker container). If clang is installed, they can't find a wasm c++ standard library to link to. nvtptx64-nvidia-cuda fails in rustc saying it can't find std. The rust platforms support page says that std is supported on cuda so this is surprising. dist-i586-gnu-i586-i686-musl can't find the C++ compiler. There is only a musl-gcc and no musl-g++ in /musl-i586/bin/. The Docker image probably needs tweaking.
4dbf822
to
1fa48cf
Compare
In the new version I have rebased on top of the new changes and solved the test failure for armhf-gnu. @rustbot label: +S-waiting-on-review -S-waiting-on-author |
@bors r+ |
📌 Commit 1fa48cf has been approved by |
☀️ Test successful - checks-actions |
See #83661 |
Get tests passing again using the riscv64gc-unknown-linux-gnu docker image.
Test with
linkcheck
Linkcheck tests that interdocument links in the documentation are correct. Some interdocument links go between rustc and tools (such as rustdoc and cargo). When cross compiling, rustc is built for the host while some tools are built for the target. This goes for the documentation too. Because of this, links in the rustc documentation reffering to cargo or rustdoc documentation look broken.
This issue is worked around by disabling linkcheck for cross compilation builds.
run-make tests
#78911 seems to happen because
--target
was not passed torustc
, but the target linker was specified, causing the target linker to be called with options intended for the host.Resolves #78911
In a separate issue,
issue-36710
was trying to run a binary built for the target on the host system. This will not work for any platform usingremote-test-server
/client
(such as riscv64). I don't know of a way of skipping those platforms specifically, so I set this test to skip only on riscv64 for now.