-
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
check host's libstdc++ version when using ci llvm #125411
Conversation
rustbot has assigned @albertlarsan68. Use |
r? Mark-Simulacrum |
This comment has been minimized.
This comment has been minimized.
f2d2bc4
to
1c38c46
Compare
src/bootstrap/src/core/sanity.rs
Outdated
if !build.config.dry_run() && build.config.llvm_from_ci { | ||
let cxx = build.cxx(build.build).unwrap(); | ||
let mut cxx_cmd = Command::new(cxx); | ||
cxx_cmd.arg("-dumpversion"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this checking the compiler version rather than libstdcxx version? These are fairly likely to be the same if the compiler is gcc, but not otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought it was the case for any c++ compiler
rust/src/bootstrap/src/core/sanity.rs
Line 112 in 1c38c46
// In case the user has a custom setup that includes a recent libstdc++ with an old c++ compiler, this information might be useful to them. |
I have to check if there is a better way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The compiler and the used C++ standard library are independent. gcc will usually use libstdc++ of the same version (but isn't required). clang on Linux will usually use some libstdc++ version -- in this case the compiler version and libstdc++ version have no relation at all. clang on other platforms like macos will use libc++, in which case the clang version and libc++ version will likely match. Of course, libstdc++ and libc++ are ABI incompatible as well :)
(Not sure whether our apple builders link against libstdc++ or libc++.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we check libc++ version too? If so, what would be a good threshold for it?
I suppose we don't need to check for it. ABI mismatch only occurs when using download-ci-llvm and ci llvm is built from our builders which use libstdc++.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
4c06ca3
to
c5755fa
Compare
|
@rustbot ready |
@@ -35,6 +36,10 @@ const STAGE0_MISSING_TARGETS: &[&str] = &[ | |||
// just a dummy comment so the list doesn't get onelined | |||
]; | |||
|
|||
/// Minimum version threshold for libstdc++ required when using prebuilt LLVM | |||
/// from CI (with`llvm.download-ci-llvm` option). | |||
const LIBSTDCXX_MIN_VERSION_THRESHOLD: usize = 8; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is minimum really the right thing here? I'd expect that we need an exact match?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unless there is a breaking change, different versions can be compatible (just like libc). It doesn't need to be the same version.
I suspect we'll hit problems and need to revert & re-land with fixes, just based on something being off (e.g., cxx invocation needing more flags or similar) but this seems OK to start with. @bors r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (50297bb): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Warning ⚠: The following benchmark(s) failed to build:
cc @rust-lang/wg-compiler-performance Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results (primary -3.1%, secondary -4.3%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeResults (secondary -0.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: missing data |
Hum, benchmarking bootstrapping broke 👀 |
Interesting.. Is there a way to check build logs of benchmark runner? |
https://perf.rust-lang.org/status.html click on |
The runner is using libstdc++ version 7 which is old. Can we use more recent version? The main reason for setting version 8 as the minimum threshold is that version 7 is not compatible with >=8 (see #110472). |
cc @Mark-Simulacrum on that |
let compiler = builder.cxx(self.target).unwrap(); | ||
let mut cmd = Command::new(compiler); | ||
|
||
let executable = out_dir.join("libcxx-version"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let executable = out_dir.join("libcxx-version"); | |
let executable = out_dir.join("libcxx-version.exe"); |
How did it pass CI on Windows?
It trivially fails for me locally, because there's no libcxx-version
, only libcxx-version.exe
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#126086 should handle this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it passed because windows-gnu CI uses env that disables llvm download?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it passed because windows-gnu CI uses env that disables llvm download?
Yeah, most likely.
use windows compatible executable name for libcxx-version Resolves #rust-lang#125411 (comment)
Rollup merge of rust-lang#126086 - onur-ozkan:use-exe, r=petrochenkov use windows compatible executable name for libcxx-version Resolves #rust-lang#125411 (comment)
On the perf collector, we have GCC 7.5, which has libstdcxx release 7, sadly. I would suggest that we revert this PR if we don't find a way to update the GCC on the collector quickly (I'm not sure if updating the GCC there wouldn't cause some side effects). Btw, I think that we should be setting |
It's not arbitrarily selected number, see #110472 (comment). |
Right, but the fact that 8 works in this case isn't a general fix. If the .so file is built with 9, shouldn't the minimum also be 9? Maybe for libLLVM.so specifically in this case 8 is indeed enough for everyone, but it seems difficult to find the correct version, in general (e.g. once we update GCC on CI sometime in the future). |
Setting the threshold to match the version we use in the CI builder would be a solid fix, but it may limit the number of people who can utilize CI LLVM. AFAIK, previous libstdcxx versions can be compatible unless they are excessively outdated. |
The trade-off here is either ensuring that the threshold version is always correct (by ensuring it matches with the libstdcxx version in CI LLVM builder using some script) or manually finding and updating the version in the bootstrap. Your suggestion seems much more reliable here. |
The specific problem with libstdc++ 7 here is that it did not yet have a stable C++ 17 ABI. It is generally not necessary to match the libstdc++ version used to build libLLVM.so exactly (the worst that can usually happen is undefined symbol errors, and I think even that isn't possible because we're linking libstdc++ statically). The C++ 17 ABI is only officially stable since libstdc++ 9, but in practice the ABI of types currently used by the libLLVM <-> rustc_llvm interface didn't change between 8 -> 9 either, which is why it works as a minimum version. |
…ck, r=<try> Remove libstdc++ version check error This keeps the error message from rust-lang#125411, but removes the `exit(1)` call. This PR is mostly a hotfix to unblock bootstrap benchmarks in rustc-perf. However, I think that it might be better to just print a warning, in general. If the ABI version does not match, the build might or might not work locally (as we can see on rustc-perf, where it works even if the reported ABI is 7). If it does not work (and **if** we can always recognize this during the LLVM wrapper build, instead of having some silent miscompilations), then the user will have to update their libstdc++ anyway, the error does not help them out on its own. So it should be enough to just provide a better error message, without blocking the build. But I'm not adamant on that, I just want to unblock bootstrap benchmarks until we can find a way to update libstdc++ on the collector machine. CC `@onur-ozkan` r? `@Mark-Simulacrum`
…ck, r=Mark-Simulacrum Remove libstdc++ version check error This keeps the error message from rust-lang#125411, but removes the `exit(1)` call. This PR is mostly a hotfix to unblock bootstrap benchmarks in rustc-perf. However, I think that it might be better to just print a warning, in general. If the ABI version does not match, the build might or might not work locally (as we can see on rustc-perf, where it works even if the reported ABI is 7). If it does not work (and **if** we can always recognize this during the LLVM wrapper build, instead of having some silent miscompilations), then the user will have to update their libstdc++ anyway, the error does not help them out on its own. So it should be enough to just provide a better error message, without blocking the build. But I'm not adamant on that, I just want to unblock bootstrap benchmarks until we can find a way to update libstdc++ on the collector machine. CC `@onur-ozkan` r? `@Mark-Simulacrum`
…k-Simulacrum Remove libstdc++ version check error This keeps the error message from rust-lang/rust#125411, but removes the `exit(1)` call. This PR is mostly a hotfix to unblock bootstrap benchmarks in rustc-perf. However, I think that it might be better to just print a warning, in general. If the ABI version does not match, the build might or might not work locally (as we can see on rustc-perf, where it works even if the reported ABI is 7). If it does not work (and **if** we can always recognize this during the LLVM wrapper build, instead of having some silent miscompilations), then the user will have to update their libstdc++ anyway, the error does not help them out on its own. So it should be enough to just provide a better error message, without blocking the build. But I'm not adamant on that, I just want to unblock bootstrap benchmarks until we can find a way to update libstdc++ on the collector machine. CC `@onur-ozkan` r? `@Mark-Simulacrum`
If the host's libstdc++ version is too old using ci-llvm may result in an ABI mismatch between the local libstdc++ and libLLVM.so. This PR adds a sanity check to immediately fail at the beginning of the bootstrap before starting the actual build. I am not sure if '8' is the best threshold, but it should be a good start and we can increase it anytime if needed.
Fixes #123037