Skip to content

Statically linking libc++ requires disabling static-libstdcpp #94983

Open
@djkoloski

Description

@djkoloski
Contributor

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++.

Activity

compiler-errors

compiler-errors commented on Mar 18, 2022

@compiler-errors
Member

+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

jonhoo commented on Mar 21, 2022

@jonhoo
Contributor

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

hvdijk commented on May 22, 2022

@hvdijk
Contributor

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

psumbera commented on May 23, 2022

@psumbera
Contributor

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

psumbera commented on May 26, 2022

@psumbera
Contributor

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).

added
T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
A-linkageArea: linking into static, shared libraries and binaries
A-contributor-roadblockArea: Makes things more difficult for new or seasoned contributors to Rust
on Apr 9, 2023
jyn514

jyn514 commented on Apr 9, 2023

@jyn514
Member

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++.

added
I-prioritizeIssue: Indicates that prioritization has been requested for this issue.
on Apr 9, 2023

5 remaining items

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-contributor-roadblockArea: Makes things more difficult for new or seasoned contributors to RustA-linkageArea: linking into static, shared libraries and binariesP-mediumMedium priorityT-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @jonhoo@hvdijk@compiler-errors@psumbera@apiraino

        Issue actions

          Statically linking `libc++` requires disabling `static-libstdcpp` · Issue #94983 · rust-lang/rust