bootstrap: untangle static-libstdcpp & llvm-tools

[jonhoo]

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 #94719.

[rust-highfive]

r? @Mark-Simulacrum

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

[Mark-Simulacrum]

My expectation was that we would flip the default slightly more conservatively -- just when llvm-tools was enabled -- but I actually think this is probably the better option overall, presuming we can get it past CI and such :)

@bors r+ rollup=iffy

[bors]

📌 Commit ca82e6c has been approved by Mark-Simulacrum

[bors]

⌛ Testing commit ca82e6c with merge 737ef08...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 737ef08 to master...

[rust-timer]

Finished benchmarking commit (737ef08): comparison url.

Summary: This benchmark run did not return any relevant results.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

[cuviper]

The new default was a surprise for me when testing a nightly build on Fedora, so let's make sure it's in the release notes.

@rustbot label: +relnotes

[jonhoo]

@cuviper Out of curiosity — how did the surprise manifest?

[cuviper]

@jonhoo I didn't have the C++ static libraries in the build root. So compiler_file(..., "libstdc++.a") runs c++ -print-file-name=libstdc++.a, which "helpfully" outputs the name as-is when it's not found, rather than an absolute path like /usr/lib/gcc/x86_64-redhat-linux/11/libstdc++.a when it does exist. Then rustc_llvm's build script gets an empty path.parent(), which eventually leads to error: empty search path given via `-L` .

I suppose we could sanity-check the existence of libstdc++.a in bootstrap, and error more gracefully if it was requested but not actually found (Path::exists). But even when I do have it on my dev machine, the change is still relnotes-worthy IMO.

[jonhoo]

Oh, yeah, it'd be nice to do that to be more helpful. I definitely agree with adding this to relnotes though!

[cuviper]

FWIW, I just found that someone else had the same issue on zulip:
https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/.E2.9C.94.20can't.20build.20rustc_llvm/near/275557132

[mati865]

FWIW there is simillar report at #94983

[petrochenkov]

@jonhoo
Apparently some of these changes broke builds with LLD.

Right now LLVM build fails at configuration step, and I see the next things in my build logs:

Performing C++ SOURCE FILE Test CXX_SUPPORTS_CUSTOM_LINKER failed with the following output:
Change Dir: C:/msys64/home/we/rust/build/x86_64-pc-windows-gnu/llvm/build/CMakeFiles/CMakeTmp

Run Build Command(s):C:/ProgramData/chocolatey/bin/ninja.exe cmTC_60dd7 && [1/2] Building CXX object CMakeFiles/cmTC_60dd7.dir/src.cxx.obj

[2/2] Linking CXX executable cmTC_60dd7.exe

FAILED: cmTC_60dd7.exe 

cmd.exe /C "cd . && C:\msys64\mingw64\bin\g++.exe -ffunction-sections -fdata-sections -m64  -fuse-ld=lld -Wl,-Bsymbolic -static-libstdc++ CMakeFiles/cmTC_60dd7.dir/src.cxx.obj -o cmTC_60dd7.exe -Wl,--out-implib,libcmTC_60dd7.dll.a -Wl,--major-image-version,0,--minor-image-version,0  -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."

lld: error: unknown argument: -Bsymbolic

collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.



Source file was:
int main() { return 0; }

Looks like LLD doesn't support -Bsymbolic, but previously the code path generating it wasn't reached with default LLVM build options.

EDIT: Or maybe LLD doesn't support -Bsymbolic on my specific target (x86_64-pc-windows-gnu) because it's not ELF.

[petrochenkov]

Yep, something like this should fix the problem:

--- a/src/bootstrap/native.rs
+++ b/src/bootstrap/native.rs
@@ -568,7 +568,7 @@ fn configure_cmake(
     // We also do this if the user explicitly requested static libstdc++.
     if builder.config.llvm_static_stdcpp {
         if !target.contains("msvc") && !target.contains("netbsd") {
-            if target.contains("apple") {
+            if target.contains("apple") || target.contains("windows") {
                 ldflags.push_all("-static-libstdc++");
             } else {
                 ldflags.push_all("-Wl,-Bsymbolic -static-libstdc++");

The code is not LLD-specific because LD ignores -Bsymbolic on Windows anyway.

[mati865]

This is true, it's noop for ld.bdf when targeting Winsows. Maybe it would be useful to ignore it in LLD though?

[petrochenkov]

@mati865

Maybe it would be useful to ignore it in LLD though?

Maybe.
Many ELF-specific options are already ignored by mingw LLD driver for compatibility, I guess they were just added in ad hoc way based on popularity / people's requests.

[jonhoo]

Huh, interesting — I wonder why this worked in the past then. I haven't changed any of the target.contains filters, which suggests it was only working "by accident" on Windows in that no-one had tried to enable static-libstdcpp (or llvm-tools?) there before? Note that there is already a !target.contains("msvc") in there, so there's clearly been some thinking about this in the past. I don't know enough about Windows to say for sure what the "right" approach here should be.

[mati865]

The key factor here is using LLD.
Ld.bfd silently ignores this option but LLD is more explicit. Probably nobody was using with LLD as the linker and enabled LLVM tools at same time for this platform.

[petrochenkov]

Apparently some of these changes broke builds with LLD.

Fixed in #95266