Open
Description
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:
- If
static-libstdcpp
is set to true, thenbootstrap/compile.rs
will askclang++
wherelibstdc++.a
is located. - For pure-LLVM toolchains, only
libc++.a
is provided andclang++
will unhelpfully return "libstdc++.a
".compile.rs
stores this inLLVM_STATIC_STDCPP
. rustc_llvm
's build script checks whetherLLVM_STATIC_STDCPP
is set. Seeing that it is, it addscargo:rustc-link-search=native=<PARENT_DIR>
to the command line where<PARENT_DIR>
is the directory containingLLVM_STATIC_STDCPP
.- Because there is no parent directory, this winds up adding
-L native=
, which triggers the error "empty search path given via-L
" inrustc_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++
.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
compiler-errors commentedon Mar 18, 2022
+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 commentedon Mar 21, 2022
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 considerslibstdc++
at the moment. My thinking here is that we should fixstatic-libstdcpp
to be "libc++ aware", where iflibc++
is being used, it should pass the "appropriate" options instead of continuing to assumelibstdc++
everywhere. Which is to say I think the bug is actually in step 1, which should realize it ought to be asking forlibc++.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 commentedon May 22, 2022
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, unlessstatic-libstdcpp = false
is also set.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 commentedon May 23, 2022
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 commentedon May 26, 2022
My issue was already reported here: #97260 (including working patch file).
jyn514 commentedon Apr 9, 2023
@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++
andlibstdc++
.5 remaining items