Statically linking libc++ requires disabling static-libstdcpp

[djkoloski]

In 737ef08, the default value of static-libstdcpp was changed from false to true. When statically linking libc++ on linux, this has a rather unfortunate cascade of effects:

1. If static-libstdcpp is set to true, then bootstrap/compile.rs will ask clang++ where libstdc++.a is located.
2. For pure-LLVM toolchains, only libc++.a is provided and clang++ will unhelpfully return "libstdc++.a". compile.rs stores this in LLVM_STATIC_STDCPP.
3. rustc_llvm's build script checks whether LLVM_STATIC_STDCPP is set. Seeing that it is, it adds cargo:rustc-link-search=native=<PARENT_DIR> to the command line where <PARENT_DIR> is the directory containing LLVM_STATIC_STDCPP.
4. Because there is no parent directory, this winds up adding -L native=, which triggers the error "empty search path given via -L" in rustc_session/src/search_paths.rs.

To get the behavior that we actually want, we need to fall into the case where LLVM_STATIC_STDCPP is not defined, and instead add -stdlib=libc++ to cxxflags. To do so, we have to set static-libstdcpp = false in config.toml. This is unintuitive behavior as it appears that we're disabling static linking entirely, but in reality we're just statically linking against libc++ instead of libstdc++.

[compiler-errors]

+1, was affected by the "empty search path" bug when trying to build stage1 from a clean centos8. Was overwhelmingly unclear that I needed to install libstdc++-static to fix.

[jonhoo]

Huh, yeah, that definitely does seem weird. I wonder where the right place to fix this is though. It does feel like static-libstdcpp is slightly too low-level a setting at the moment in that it only considers libstdc++ at the moment. My thinking here is that we should fix static-libstdcpp to be "libc++ aware", where if libc++ is being used, it should pass the "appropriate" options instead of continuing to assume libstdc++ everywhere. Which is to say I think the bug is actually in step 1, which should realize it ought to be asking for libc++.a instead. And then also in the #94832 logic to pass a different flag (-static?) instead of -static-libstdc++ as part of the linker flags.

[hvdijk]

This has become more visible now that 1.61.0 has been released. 1.61.0 no longer builds on pure LLVM systems with libc++, even if use-libcxx = true is set, unless static-libstdcpp = false is also set.

It does feel like static-libstdcpp is slightly too low-level a setting at the moment in that it only considers libstdc++ at the moment. My thinking here is that we should fix static-libstdcpp to be "libc++ aware", where if libc++ is being used, it should pass the "appropriate" options instead of continuing to assume libstdc++ everywhere.

My initial thought is the opposite. The name static-libstdcpp and its description are both highly specific to libstdc++, and the option already has no effect on targets that normally do not use libstdc++, so my thinking is that this should be extended to all cases where libstdc++ is not used.

[psumbera]

I'm not able to build 1.61.0 on Solaris now. There is no libstdc++.a bundled with Solaris GCC. And there is also no libc++. Any suggestion?

[psumbera]

I'm not able to build 1.61.0 on Solaris now. There is no libstdc++.a bundled with Solaris GCC. And there is also no libc++. Any suggestion?

My issue was already reported here: #97260 (including working patch file).

[jyn514]

My thinking here is that we should fix static-libstdcpp to be "libc++ aware", where if libc++ is being used, it should pass the "appropriate" options instead of continuing to assume libstdc++ everywhere. Which is to say I think the bug is actually in step 1, which should realize it ought to be asking for libc++.a instead. And then also in the #94832 logic to pass a different flag (-static?) instead of -static-libstdc++ as part of the linker flags.

@jonhoo do you have time to follow-up on this? It seems like a reasonable fix but I'm not familiar with the difference between libc++ and libstdc++.

[jonhoo]

I probably won't have a chance to get to this for a week or two unfortunately. I think I agree with the more recent discussion now though in that we should just fix step 3 from OP's post so that if the parent directory is empty we don't add it to -L.

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-medium

[jonhoo]

Given my recent change of jobs, I probably won't have a chance to pick this up again. Sorry about that! I still think the proposed fix is the way to go though!