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.

Sign up for GitHub

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

Jump to bottom

Statically compile libstdc++ everywhere if asked #94719

Merged
merged 1 commit into from
Mar 11, 2022
Merged

Statically compile libstdc++ everywhere if asked #94719

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 12 additions & 12 deletions src/bootstrap/native.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -259,18 +259,6 @@ impl Step for Llvm {
cfg.define("LLVM_LINK_LLVM_DYLIB", "ON");
}

// 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 {
if !target.contains("msvc") && !target.contains("netbsd") {
if target.contains("apple") {
ldflags.push_all("-static-libstdc++");
} else {
ldflags.push_all("-Wl,-Bsymbolic -static-libstdc++");
}
}
}

if target.starts_with("riscv") && !target.contains("freebsd") {
// RISC-V GCC erroneously requires linking against
// `libatomic` when using 1-byte and 2-byte C++
Expand Down Expand Up @@ -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/src/ci/run.sh

Line 72 in 03918ba

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.

if !target.contains("msvc") && !target.contains("netbsd") {
if target.contains("apple") {
ldflags.push_all("-static-libstdc++");
} else {
ldflags.push_all("-Wl,-Bsymbolic -static-libstdc++");
}
}
}

cfg.define("CMAKE_SHARED_LINKER_FLAGS", &ldflags.shared);
cfg.define("CMAKE_MODULE_LINKER_FLAGS", &ldflags.module);
cfg.define("CMAKE_EXE_LINKER_FLAGS", &ldflags.exe);
Expand Down