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

Statically compile libstdc++ everywhere if asked #94719

Merged
merged 1 commit into from
Mar 11, 2022

Conversation

jonhoo
Copy link
Contributor

@jonhoo jonhoo commented Mar 8, 2022

PR #93918 made it so that -static-libstdc++ was only set in one place,
and was only set during linking, but accidentally also made it so that
it is no longer passed when building LLD, only when building LLVM
itself. This moves the logic for setting -static-libstdc++ in the
linker flags to configure_cmake so that it takes effect for all CMake
invocations in native.rs.

As a side-effect, this also causes libstdc++ to be statically compiled
into sanitizers, whereas previously the llvm-static-stdcpp flag had no
effect on sanitizers. It also makes it so that LLD will be compiled
statically if llvm-tools-enabled is set, even though previously it was
only linked statically if llvm-static-stdcpp was set explicitly. Both
of these seem like they match expected behavior than what was there
prior to #93918.

@rust-highfive
Copy link
Collaborator

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 8, 2022
@jonhoo
Copy link
Contributor Author

jonhoo commented Mar 8, 2022

I think on balance I've fixed more issues than I've caused 😅 Found this one due to a case where I tried to do a wasm32-wasi build using a rustc distribution built on a new-ish host on a very hold host with an ancient GLIBCXX, and it errored with a GLIBCXX version mismatch since was32 targets link with rust-lld by default.

@jonhoo
Copy link
Contributor Author

jonhoo commented Mar 8, 2022

For reference, the code that used to live in configure_cmake that used to do this is: https://github.com/rust-lang/rust/pull/93918/files#diff-ca6526d91d41c31fad645c46417e0f1ce61e324542994e8c8b72b1f7a08c91bdL527

And, actually, looking at it it used to apply to sanitizers as well, so I think the only actual semantics change here is that -static-libstdc++ will apply to LLD and sanitizers if llvm-tools-enabled even if llvm-static-stdcpp isn't.

PR rust-lang#93918 made it so that `-static-libstdc++` was only set in one place,
and was only set during linking, but accidentally also made it so that
it is no longer passed when building LLD or sanitizers, only when
building LLVM itself. This moves the logic for setting
`-static-libstdc++` in the linker flags back to `configure_cmake` so
that it takes effect for all CMake invocations in `native.rs`.

As a side-effect, this also causes libstdc++ to be statically compiled
into sanitizers and LLD if `llvm-tools-enabled` is set but
`llvm-static-stdcpp` is not, even though previously it was only linked
statically if `llvm-static-stdcpp` was set explicitly. But that seems
more like the expected behavior anyway.
@jonhoo
Copy link
Contributor Author

jonhoo commented Mar 8, 2022

I force-pushed a change that just changes the commit message to be accurate with respect to sanitizers.

@@ -576,6 +564,18 @@ fn configure_cmake(
ldflags.push_all(&flags);
}

// For distribution we want the LLVM tools to be *statically* linked to libstdc++.
// We also do this if the user explicitly requested static libstdc++.
if builder.config.llvm_tools_enabled || builder.config.llvm_static_stdcpp {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We blanket enable llvm-static-stdcpp in our CI (see

RUST_CONFIGURE_ARGS="$RUST_CONFIGURE_ARGS --enable-llvm-static-stdcpp"
), so I'm wondering if it makes sense to remove the llvm-tools enablement here -- it's not obvious to me that it should be present.

It looks like that was originally added in #50336, but it seems like an odd thing to force opt-in users of the build system to with an orthogonal flag. Maybe you have a better sense here though!

I think this somewhat makes this PR a clearer "yes" to me, since if we're migrating to a simpler story of only enabling static stdcpp if asked explicitly, then doing that for everything makes sense. But if that's gated on llvm tools being enabled, it feels weird for that to apply to "not tools".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a tough call. When you need llvm-tools, you'll very often want them with static libstdc++, because otherwise they may just not run on whatever host you try running them on, and you won't be able to tell until a user with an old host is bitten by it. But at the same time, as you point out, there's no fundamental reason they need to be coupled (at least as far as I can tell), which suggests the two flags should be decoupled. I think of this as an anti-footgun of having llvm-tools imply static-libstdc++ because builders may not have thought through the implications of not linking it statically (they may not even be aware of the static-stdcpp flag).

Which is all to say — I think decoupling them gives more flexibility to builders, but at the cost of making it harder to get to a functioning build for someone who's trying to replicate the upstream build process. Which of those is more important, I'm not sure.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. Yes, that makes sense. I think we should probably be changing the default for static stdcpp, then, rather than specifically checking tools here, but that seems like a change that needs it's own PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, yeah, I like that idea! Can submit a PR for that tomorrow. And then you'd want this PR to just switch on llvm_static_stdcpp?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I think we should do a separate PR that changes the if condition to just be llvm_static_stdcpp and flips its default. Otherwise, in the interrim (however short) we'll be changing the behavior of the code.

@Mark-Simulacrum Mark-Simulacrum added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 8, 2022
@tmiasko
Copy link
Contributor

tmiasko commented Mar 8, 2022

As a side-effect, this also causes libstdc++ to be statically compiled into sanitizers

Sanitizers don't use or link to the C++ standard library. It would be better to avoid adding -static-libstdc++ there since leads to warning about unused arguments. Though, it seems acceptable since -nodefaultlibs / -nostdlib++ take precedence.

@jonhoo
Copy link
Contributor Author

jonhoo commented Mar 8, 2022

Prior to #93918, we were passing -static-libstdc++ to the sanitizers too, but we were doing so through both CXXFLAGS and LDFLAGS, which caused a lot more noise. Now that it's just LDFLAGS, I'm inclined to keep the logic in just one place (configure_cmake). This also guards us against the hypothetical case where the sanitizers do for some reason need something from stdc++ in the future.

@jonhoo
Copy link
Contributor Author

jonhoo commented Mar 9, 2022

I actually wonder if this needs a backport (along with #94466), since otherwise users of 1.60 will just get #93918, which in turn means their lld won't be statically linked with libstdc++. It should only affect stable users who are linking with rust-lld and running on fairly old platforms, but that number probably isn't zero.

@Mark-Simulacrum
Copy link
Member

Yeah, I'm going to go ahead and unilaterally approve for beta backport, I think it makes sense to roll these two into one change from user's perspective. The alternative I think would be to back out #93918, but that seems worse to me. In any case, these changes should be fairly well-tested since they affect our shipped artifacts, and if they cause problems for distros they can locally revert fairly easily (since it just touches rustbuild).

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Mar 9, 2022

📌 Commit b328688 has been approved by Mark-Simulacrum

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 9, 2022
@Mark-Simulacrum Mark-Simulacrum added beta-accepted Accepted for backporting to the compiler in the beta channel. beta-nominated Nominated for backporting to the compiler in the beta channel. labels Mar 9, 2022
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 9, 2022
…mulacrum

Statically compile libstdc++ everywhere if asked

PR rust-lang#93918 made it so that `-static-libstdc++` was only set in one place,
and was only set during linking, but accidentally also made it so that
it is no longer passed when building LLD, only when building LLVM
itself. This moves the logic for setting `-static-libstdc++` in the
linker flags to `configure_cmake` so that it takes effect for all CMake
invocations in `native.rs`.

As a side-effect, this also causes libstdc++ to be statically compiled
into sanitizers, whereas previously the `llvm-static-stdcpp` flag had no
effect on sanitizers. It also makes it so that LLD will be compiled
statically if `llvm-tools-enabled` is set, even though previously it was
only linked statically if `llvm-static-stdcpp` was set explicitly. Both
of these seem like they match expected behavior than what was there
prior to rust-lang#93918.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 9, 2022
…mulacrum

Statically compile libstdc++ everywhere if asked

PR rust-lang#93918 made it so that `-static-libstdc++` was only set in one place,
and was only set during linking, but accidentally also made it so that
it is no longer passed when building LLD, only when building LLVM
itself. This moves the logic for setting `-static-libstdc++` in the
linker flags to `configure_cmake` so that it takes effect for all CMake
invocations in `native.rs`.

As a side-effect, this also causes libstdc++ to be statically compiled
into sanitizers, whereas previously the `llvm-static-stdcpp` flag had no
effect on sanitizers. It also makes it so that LLD will be compiled
statically if `llvm-tools-enabled` is set, even though previously it was
only linked statically if `llvm-static-stdcpp` was set explicitly. Both
of these seem like they match expected behavior than what was there
prior to rust-lang#93918.
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Mar 9, 2022
…mulacrum

Statically compile libstdc++ everywhere if asked

PR rust-lang#93918 made it so that `-static-libstdc++` was only set in one place,
and was only set during linking, but accidentally also made it so that
it is no longer passed when building LLD, only when building LLVM
itself. This moves the logic for setting `-static-libstdc++` in the
linker flags to `configure_cmake` so that it takes effect for all CMake
invocations in `native.rs`.

As a side-effect, this also causes libstdc++ to be statically compiled
into sanitizers, whereas previously the `llvm-static-stdcpp` flag had no
effect on sanitizers. It also makes it so that LLD will be compiled
statically if `llvm-tools-enabled` is set, even though previously it was
only linked statically if `llvm-static-stdcpp` was set explicitly. Both
of these seem like they match expected behavior than what was there
prior to rust-lang#93918.
m-ou-se added a commit to m-ou-se/rust that referenced this pull request Mar 10, 2022
…mulacrum

Statically compile libstdc++ everywhere if asked

PR rust-lang#93918 made it so that `-static-libstdc++` was only set in one place,
and was only set during linking, but accidentally also made it so that
it is no longer passed when building LLD, only when building LLVM
itself. This moves the logic for setting `-static-libstdc++` in the
linker flags to `configure_cmake` so that it takes effect for all CMake
invocations in `native.rs`.

As a side-effect, this also causes libstdc++ to be statically compiled
into sanitizers, whereas previously the `llvm-static-stdcpp` flag had no
effect on sanitizers. It also makes it so that LLD will be compiled
statically if `llvm-tools-enabled` is set, even though previously it was
only linked statically if `llvm-static-stdcpp` was set explicitly. Both
of these seem like they match expected behavior than what was there
prior to rust-lang#93918.
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Mar 10, 2022
…mulacrum

Statically compile libstdc++ everywhere if asked

PR rust-lang#93918 made it so that `-static-libstdc++` was only set in one place,
and was only set during linking, but accidentally also made it so that
it is no longer passed when building LLD, only when building LLVM
itself. This moves the logic for setting `-static-libstdc++` in the
linker flags to `configure_cmake` so that it takes effect for all CMake
invocations in `native.rs`.

As a side-effect, this also causes libstdc++ to be statically compiled
into sanitizers, whereas previously the `llvm-static-stdcpp` flag had no
effect on sanitizers. It also makes it so that LLD will be compiled
statically if `llvm-tools-enabled` is set, even though previously it was
only linked statically if `llvm-static-stdcpp` was set explicitly. Both
of these seem like they match expected behavior than what was there
prior to rust-lang#93918.
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 10, 2022
Rollup of 7 pull requests

Successful merges:

 - rust-lang#93950 (Use modern formatting for format! macros)
 - rust-lang#94274 (Treat unstable lints as unknown)
 - rust-lang#94368 ([1/2] Implement macro meta-variable expressions)
 - rust-lang#94719 (Statically compile libstdc++ everywhere if asked)
 - rust-lang#94728 (Only emit pointer-like metadata for `Box<T, A>` when `A` is ZST)
 - rust-lang#94790 (enable portable-simd doctests in Miri)
 - rust-lang#94811 (Update browser-ui-test version)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 1cf8793 into rust-lang:master Mar 11, 2022
@rustbot rustbot added this to the 1.61.0 milestone Mar 11, 2022
@jonhoo
Copy link
Contributor Author

jonhoo commented Mar 11, 2022

Wooo! Let me get you a PR that changes the default 👍

@jonhoo jonhoo deleted the enable-static-lld branch March 11, 2022 01:52
jonhoo pushed a commit to jonhoo/rust that referenced this pull request Mar 11, 2022
Previously, the static-libstdcpp setting was tied to llvm-tools such
that enabling the latter always enabled the latter. This seems
unfortunate, since it is entirely reasonable for someone to want to
_not_ statically link stdc++, but _also_ want to build the llvm-tools.
This patch therefore separates the two settings such that neither
implies the other.

On its own, that would change the default behavior in a way that's
likely to surprise users. Specifically, users who build llvm-tools
_likely_ want those tools to be statically compiled against libstdc++,
since otherwise users with older GLIBCXX will be unable to run the
vended tools. So, we also flip the default for the `static-libstdcpp`
setting such that builds always link statically against libstdc++ by
default, but it's _possible_ to opt out.

See also rust-lang#94719.
@jonhoo
Copy link
Contributor Author

jonhoo commented Mar 11, 2022

Opened #94832

bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 13, 2022
bootstrap: untangle static-libstdcpp & llvm-tools

Previously, the static-libstdcpp setting was tied to llvm-tools such
that enabling the latter always enabled the latter. This seems
unfortunate, since it is entirely reasonable for someone to want to
_not_ statically link stdc++, but _also_ want to build the llvm-tools.
This patch therefore separates the two settings such that neither
implies the other.

On its own, that would change the default behavior in a way that's
likely to surprise users. Specifically, users who build llvm-tools
_likely_ want those tools to be statically compiled against libstdc++,
since otherwise users with older GLIBCXX will be unable to run the
vended tools. So, we also flip the default for the `static-libstdcpp`
setting such that builds always link statically against libstdc++ by
default, but it's _possible_ to opt out.

See also rust-lang#94719.
@Mark-Simulacrum Mark-Simulacrum removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Mar 14, 2022
@Mark-Simulacrum Mark-Simulacrum modified the milestones: 1.61.0, 1.60.0 Mar 14, 2022
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 14, 2022
…ulacrum

[beta] backports

* Update LLVM submodule rust-lang#94764
* Statically compile libstdc++ everywhere if asked rust-lang#94719
* Downgrade #[test] on macro call to warning rust-lang#94624
* Delay bug in expr adjustment when check_expr is called multiple times rust-lang#94596
* bootstrap: correct reading of flags for llvm rust-lang#94466
* Check method input expressions once rust-lang#94438
* remove feature gate in control_flow examples rust-lang#94283

r? `@Mark-Simulacrum`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta-accepted Accepted for backporting to the compiler in the beta channel. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants