From 7b0ae725fa4d45b8ba1cd05605e29167200be7ca Mon Sep 17 00:00:00 2001 From: Chandler Carruth Date: Tue, 18 Jun 2024 16:56:56 +0200 Subject: [PATCH] Fix linking to not look for a system libstdc++. (#4060) Not sure what changed (I think an upstream LLVM change, but maybe a Linux distro change), but several folks have been running into problems finding a standard C++ library when running the Carbon link step. It was actually breaking our example build when LLD didn't find the right libstdc++ install, but it finds one reliably on our build bots and sometimes for some of the developers. For now, just remove the C++ standard library from the link. We're not doing that level of interop, and the plan is really to do that not with the system standard C++ library but by building and bundling libc++ with the installed toolchain. Left a comment explaining what's going on here. --- toolchain/driver/driver.cpp | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/toolchain/driver/driver.cpp b/toolchain/driver/driver.cpp index cbd01afdd992..41fd4f7e7197 100644 --- a/toolchain/driver/driver.cpp +++ b/toolchain/driver/driver.cpp @@ -950,6 +950,14 @@ auto Driver::Link(const LinkOptions& options, // Use LLD, which we provide in our install directory, for linking. clang_args.push_back("-fuse-ld=lld"); + // Disable linking the C++ standard library until can build and ship it as + // part of the Carbon toolchain. This clearly won't work once we get into + // interop, but for now it avoids spurious failures and distraction. The plan + // is to build and bundle libc++ at which point we can replace this with + // pointing at our bundled library. + // TODO: Replace this when ready. + clang_args.push_back("-nostdlib++"); + // Add OS-specific flags based on the target. AddOSFlags(codegen_options.target, clang_args);