[clang][Darwin] Prefer the toolchain-provided libc++.dylib if there is one #170303
+144
−8
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…s one When libc++ is bootstrapped with clang, the resulting clang uses the just-built libcxx headers from <install>/bin/../include/c++/v1. However, before this patch, clang would still use the system-provided libc++.dylib (usually in the Apple SDK) because it would fail to add the corresponding linker flag to find the just-built libc++. After this patch, Clang will also add `-L <install>/bin/../lib` to the linker search paths, which will allow the just-built libc++.dylib to be found. Fixes llvm#77653 rdar://107060541
tstellar
reviewed
Dec 2, 2025
Collaborator
tstellar
left a comment
tstellar
left a comment
There was a problem hiding this comment.
Have you tested this with a multi-target runtime build? My fix was slightly different so maybe you won't have the same problem, but I ran into an issue where clang would pick up the libc++ build for watchos instead of the one build for macOS. Here is an example of the error: https://github.com/llvm/llvm-project/actions/runs/18506722806/job/52742884609?pr=163026
Contributor
|
Where does this resolve in Xcode? If it goes to Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib or Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/lib/darwin then I don't think we want to be adding this, as the libraries in there don't have a usable install name. |
Member
Author
Yes, I am doing a bootstrapping build of Clang + compiler-rt + libc++ for multiple targets (well, it does that by default for compiler-rt AFAICT). However, I am running into a different issue that I am still investigating: the compiler-rt build is creating fat libraries for e.g.
It would add So if I do e.g. |
Contributor
|
It's a problem for the dylibs because you'll end up with a broken executable for rpath reasons. I don't think it makes sense to add XcodeDefault.xctoolchain/usr/lib to everyone's search paths by default. There's nothing in there that anyone should use outside of Xcode, and things that get packaged inside of Xcode. Maybe @cachemeifyoucan or https://github.com/jakepetroules have other opinions. |
Member
Author
That's only the case if you do add e.g. |
Contributor
It's not link time that's the problem but load/run time due to the |
ian-twilightcoder
requested changes
Dec 2, 2025
Contributor
ian-twilightcoder
left a comment
ian-twilightcoder
left a comment
There was a problem hiding this comment.
I think we don't generally want this behavior for clients as it adds an undesired linker search path into Xcode, I think we want something special in clang/libc++ to find the libc++ that was previously built.
Collaborator
|
I think searching for libcxx dylib in the install directory for bootstrap situation makes sense but I am very worried about ingesting such a search path in such a high priority location (before sys root). That can cause user unintentionally pick up libraries in there. I would rather if |
Member
Author
I don't understand. There's no RPATH added by this patch.
Yeah, I agree this is not ideal and it was a tradeoff I was willing to make in order to fix this issue, but I think your suggestion is strictly better.
Another option would be to ship libc++ under a subdirectory and then add e.g. |
llvmbot
added
clang
Member
|
@llvm/pr-subscribers-clang-driver Author: Louis Dionne (ldionne) ChangesWhen libc++ is bootstrapped with clang, the resulting clang uses the just-built libcxx headers from <install>/bin/../include/c++/v1. However, before this patch, clang would still use the system-provided libc++.dylib (usually in the Apple SDK) because it would fail to add the corresponding linker flag to find the just-built libc++. After this patch, Clang will also add Fixes #77653 Full diff: https://github.com/llvm/llvm-project/pull/170303.diff 10 Files Affected:
diff --git a/clang/lib/Driver/ToolChains/Darwin.cpp b/clang/lib/Driver/ToolChains/Darwin.cpp
index fc3cd9030f71d..6665b54ca473d 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -2846,11 +2846,49 @@ void AppleMachO::AddCXXStdlibLibArgs(const ArgList &Args,
CXXStdlibType Type = GetCXXStdlibType(Args);
switch (Type) {
- case ToolChain::CST_Libcxx:
- CmdArgs.push_back("-lc++");
+ case ToolChain::CST_Libcxx: {
+ // On Darwin, we prioritize a libc++ located in the toolchain to a libc++
+ // located in the sysroot. Unlike the driver for most other platforms, on
+ // Darwin we do that by explicitly passing the library path to the linker
+ // to avoid having to add the toolchain's `lib/` directory to the linker
+ // search path, which would make other libraries findable as well.
+ //
+ // Prefering the toolchain library over the sysroot library matches the
+ // behavior we have for headers, where we prefer headers in the toolchain
+ // over headers in the sysroot if there are any. Note that it's important
+ // for the header search path behavior to match the link-time search path
+ // behavior to ensure that we link the program against a library that
+ // matches the headers that were used to compile it.
+ //
+ // Otherwise, we end up compiling against some set of headers and then
+ // linking against a different library (which, confusingly, shares the same
+ // name) which may have been configured with different options, be at a
+ // different version, etc.
+ SmallString<128> InstallLib = llvm::sys::path::parent_path(getDriver().Dir);
+ llvm::sys::path::append(InstallLib, "lib"); // <install>/bin/../lib
+ auto Link = [&](StringRef Library) {
+ SmallString<128> Shared(InstallLib);
+ llvm::sys::path::append(Shared,
+ SmallString<4>("lib") + Library + ".dylib");
+ SmallString<128> Static(InstallLib);
+ llvm::sys::path::append(Static, SmallString<4>("lib") + Library + ".a");
+ SmallString<32> Relative("-l");
+ Relative += Library;
+
+ if (getVFS().exists(Shared)) {
+ CmdArgs.push_back(Args.MakeArgString(Shared));
+ } else if (getVFS().exists(Static)) {
+ CmdArgs.push_back(Args.MakeArgString(Static));
+ } else {
+ CmdArgs.push_back(Args.MakeArgString(Relative));
+ }
+ };
+
+ Link("c++");
if (Args.hasArg(options::OPT_fexperimental_library))
- CmdArgs.push_back("-lc++experimental");
+ Link("c++experimental");
break;
+ }
case ToolChain::CST_Libstdcxx:
// Unfortunately, -lstdc++ doesn't always exist in the standard search path;
diff --git a/clang/test/Driver/Inputs/basic_darwin_toolchain/usr/lib/libc++.dylib b/clang/test/Driver/Inputs/basic_darwin_toolchain/usr/lib/libc++.dylib
new file mode 100644
index 0000000000000..e69de29bb2d1d
diff --git a/clang/test/Driver/Inputs/basic_darwin_toolchain/usr/lib/libc++experimental.a b/clang/test/Driver/Inputs/basic_darwin_toolchain/usr/lib/libc++experimental.a
new file mode 100644
index 0000000000000..e69de29bb2d1d
diff --git a/clang/test/Driver/Inputs/basic_darwin_toolchain_static/usr/bin/.keep b/clang/test/Driver/Inputs/basic_darwin_toolchain_static/usr/bin/.keep
new file mode 100644
index 0000000000000..e69de29bb2d1d
diff --git a/clang/test/Driver/Inputs/basic_darwin_toolchain_static/usr/include/c++/v1/.keep b/clang/test/Driver/Inputs/basic_darwin_toolchain_static/usr/include/c++/v1/.keep
new file mode 100644
index 0000000000000..e69de29bb2d1d
diff --git a/clang/test/Driver/Inputs/basic_darwin_toolchain_static/usr/lib/libc++.a b/clang/test/Driver/Inputs/basic_darwin_toolchain_static/usr/lib/libc++.a
new file mode 100644
index 0000000000000..e69de29bb2d1d
diff --git a/clang/test/Driver/Inputs/basic_darwin_toolchain_static/usr/lib/libc++experimental.a b/clang/test/Driver/Inputs/basic_darwin_toolchain_static/usr/lib/libc++experimental.a
new file mode 100644
index 0000000000000..e69de29bb2d1d
diff --git a/clang/test/Driver/darwin-header-search-libcxx.cpp b/clang/test/Driver/darwin-header-search-libcxx.cpp
index cc8ec9ceb89b3..e8985a4e22b2f 100644
--- a/clang/test/Driver/darwin-header-search-libcxx.cpp
+++ b/clang/test/Driver/darwin-header-search-libcxx.cpp
@@ -92,7 +92,7 @@
// CHECK-LIBCXX-SYSROOT_AND_TOOLCHAIN-1: "-internal-isystem" "[[TOOLCHAIN]]/usr/bin/../include/c++/v1"
// CHECK-LIBCXX-SYSROOT_AND_TOOLCHAIN-1-NOT: "-internal-isystem" "[[SYSROOT]]/usr/include/c++/v1"
-// Make sure that using -nostdinc, -nostdinc++ or -nostdlib will drop both the toolchain
+// Make sure that using -nostdinc, -nostdinc++ or -nostdlibinc will drop both the toolchain
// C++ include path and the sysroot one.
//
// RUN: %clang -### %s -fsyntax-only 2>&1 \
@@ -116,7 +116,7 @@
// RUN: -isysroot %S/Inputs/basic_darwin_sdk_usr_cxx_v1 \
// RUN: -stdlib=platform \
// RUN: -nostdinc++ \
-// RUN: | FileCheck -DSYSROOT=%S/Inputs/basic_darwin_sdk_usr \
+// RUN: | FileCheck -DSYSROOT=%S/Inputs/basic_darwin_sdk_usr_cxx_v1 \
// RUN: -DTOOLCHAIN=%S/Inputs/basic_darwin_toolchain \
// RUN: --check-prefix=CHECK-LIBCXX-NOSTDINCXX %s
// CHECK-LIBCXX-NOSTDINCXX: "-cc1"
diff --git a/clang/test/Driver/darwin-link-libcxx.cpp b/clang/test/Driver/darwin-link-libcxx.cpp
new file mode 100644
index 0000000000000..1c4f31b257512
--- /dev/null
+++ b/clang/test/Driver/darwin-link-libcxx.cpp
@@ -0,0 +1,81 @@
+// UNSUPPORTED: system-windows
+
+// Tests to check that we link against the toolchain-provided libc++ built library when it is provided.
+// This is required to prefer the toolchain's libc++ over the system's libc++, which matches the behavior
+// we have for header search paths.
+
+// When libc++.dylib is NOT in the toolchain, we should use -lc++ and fall back to the libc++
+// in the sysroot.
+//
+// (1) Without -fexperimental-library.
+// RUN: %clangxx -### %s 2>&1 \
+// RUN: --target=x86_64-apple-darwin \
+// RUN: -ccc-install-dir %S/Inputs/basic_darwin_toolchain_no_libcxx/usr/bin \
+// RUN: | FileCheck -DTOOLCHAIN=%S/Inputs/basic_darwin_toolchain_no_libcxx \
+// RUN: --check-prefix=CHECK-1 %s
+// CHECK-1: "/usr/bin/ld"
+// CHECK-1: "-lc++"
+// CHECK-1-NOT: "[[TOOLCHAIN]]/usr/lib"
+//
+// (2) With -fexperimental-library.
+// RUN: %clangxx -### %s 2>&1 \
+// RUN: --target=x86_64-apple-darwin \
+// RUN: -ccc-install-dir %S/Inputs/basic_darwin_toolchain_no_libcxx/usr/bin \
+// RUN: -fexperimental-library \
+// RUN: | FileCheck -DTOOLCHAIN=%S/Inputs/basic_darwin_toolchain_no_libcxx \
+// RUN: --check-prefix=CHECK-2 %s
+// CHECK-2: "/usr/bin/ld"
+// CHECK-2: "-lc++" "-lc++experimental"
+// CHECK-2-NOT: "[[TOOLCHAIN]]/usr/lib"
+
+// When we have libc++.dylib in the toolchain, it should be used over the one in the sysroot.
+// There are a few cases worth testing.
+//
+// (1) Without -fexperimental-library.
+// RUN: %clangxx -### %s 2>&1 \
+// RUN: --target=x86_64-apple-darwin \
+// RUN: -ccc-install-dir %S/Inputs/basic_darwin_toolchain/usr/bin \
+// RUN: | FileCheck -DTOOLCHAIN=%S/Inputs/basic_darwin_toolchain \
+// RUN: --check-prefix=CHECK-3 %s
+// CHECK-3: "/usr/bin/ld"
+// CHECK-3: "[[TOOLCHAIN]]/usr/lib/libc++.dylib"
+// CHECK-3-NOT: "-lc++"
+//
+// (2) With -fexperimental-library.
+// RUN: %clangxx -### %s 2>&1 \
+// RUN: --target=x86_64-apple-darwin \
+// RUN: -ccc-install-dir %S/Inputs/basic_darwin_toolchain/usr/bin \
+// RUN: -fexperimental-library \
+// RUN: | FileCheck -DTOOLCHAIN=%S/Inputs/basic_darwin_toolchain \
+// RUN: --check-prefix=CHECK-4 %s
+// CHECK-4: "/usr/bin/ld"
+// CHECK-4: "[[TOOLCHAIN]]/usr/lib/libc++.dylib"
+// CHECK-4: "[[TOOLCHAIN]]/usr/lib/libc++experimental.a"
+// CHECK-4-NOT: "-lc++"
+// CHECK-4-NOT: "-lc++experimental"
+
+// When we have libc++.a in the toolchain instead of libc++.dylib, it should be
+// used over the one in the sysroot.
+//
+// (1) Without -fexperimental-library.
+// RUN: %clangxx -### %s 2>&1 \
+// RUN: --target=x86_64-apple-darwin \
+// RUN: -ccc-install-dir %S/Inputs/basic_darwin_toolchain_static/usr/bin \
+// RUN: | FileCheck -DTOOLCHAIN=%S/Inputs/basic_darwin_toolchain_static \
+// RUN: --check-prefix=CHECK-5 %s
+// CHECK-5: "/usr/bin/ld"
+// CHECK-5: "[[TOOLCHAIN]]/usr/lib/libc++.a"
+// CHECK-5-NOT: "-lc++"
+//
+// (2) With -fexperimental-library.
+// RUN: %clangxx -### %s 2>&1 \
+// RUN: --target=x86_64-apple-darwin \
+// RUN: -ccc-install-dir %S/Inputs/basic_darwin_toolchain_static/usr/bin \
+// RUN: -fexperimental-library \
+// RUN: | FileCheck -DTOOLCHAIN=%S/Inputs/basic_darwin_toolchain_static \
+// RUN: --check-prefix=CHECK-6 %s
+// CHECK-6: "/usr/bin/ld"
+// CHECK-6: "[[TOOLCHAIN]]/usr/lib/libc++.a"
+// CHECK-6: "[[TOOLCHAIN]]/usr/lib/libc++experimental.a"
+// CHECK-6-NOT: "-lc++"
+// CHECK-6-NOT: "-lc++experimental"
diff --git a/clang/test/Driver/experimental-library-flag.cpp b/clang/test/Driver/experimental-library-flag.cpp
index 62b007516897e..0546a09d5518b 100644
--- a/clang/test/Driver/experimental-library-flag.cpp
+++ b/clang/test/Driver/experimental-library-flag.cpp
@@ -18,6 +18,8 @@
// CHECK: -fexperimental-library
// Depending on the stdlib in use, we should (or not) pass -lc++experimental.
-// CHECK-LIBCXX: -lc++experimental
-// CHECK-LIBSTDCXX-NOT: -lc++experimental
-// CHECK-NOSTDLIB-NOT: -lc++experimental
+// Note that we don't check for `-lc++experimental` specifically, since some targets
+// like Darwin pass the path to the library explicitly instead of using `-lx`.
+// CHECK-LIBCXX: c++experimental
+// CHECK-LIBSTDCXX-NOT: c++experimental
+// CHECK-NOSTDLIB-NOT: c++experimental
|
Member
|
@llvm/pr-subscribers-clang Author: Louis Dionne (ldionne) ChangesWhen libc++ is bootstrapped with clang, the resulting clang uses the just-built libcxx headers from <install>/bin/../include/c++/v1. However, before this patch, clang would still use the system-provided libc++.dylib (usually in the Apple SDK) because it would fail to add the corresponding linker flag to find the just-built libc++. After this patch, Clang will also add Fixes #77653 Full diff: https://github.com/llvm/llvm-project/pull/170303.diff 10 Files Affected:
diff --git a/clang/lib/Driver/ToolChains/Darwin.cpp b/clang/lib/Driver/ToolChains/Darwin.cpp
index fc3cd9030f71d..6665b54ca473d 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -2846,11 +2846,49 @@ void AppleMachO::AddCXXStdlibLibArgs(const ArgList &Args,
CXXStdlibType Type = GetCXXStdlibType(Args);
switch (Type) {
- case ToolChain::CST_Libcxx:
- CmdArgs.push_back("-lc++");
+ case ToolChain::CST_Libcxx: {
+ // On Darwin, we prioritize a libc++ located in the toolchain to a libc++
+ // located in the sysroot. Unlike the driver for most other platforms, on
+ // Darwin we do that by explicitly passing the library path to the linker
+ // to avoid having to add the toolchain's `lib/` directory to the linker
+ // search path, which would make other libraries findable as well.
+ //
+ // Prefering the toolchain library over the sysroot library matches the
+ // behavior we have for headers, where we prefer headers in the toolchain
+ // over headers in the sysroot if there are any. Note that it's important
+ // for the header search path behavior to match the link-time search path
+ // behavior to ensure that we link the program against a library that
+ // matches the headers that were used to compile it.
+ //
+ // Otherwise, we end up compiling against some set of headers and then
+ // linking against a different library (which, confusingly, shares the same
+ // name) which may have been configured with different options, be at a
+ // different version, etc.
+ SmallString<128> InstallLib = llvm::sys::path::parent_path(getDriver().Dir);
+ llvm::sys::path::append(InstallLib, "lib"); // <install>/bin/../lib
+ auto Link = [&](StringRef Library) {
+ SmallString<128> Shared(InstallLib);
+ llvm::sys::path::append(Shared,
+ SmallString<4>("lib") + Library + ".dylib");
+ SmallString<128> Static(InstallLib);
+ llvm::sys::path::append(Static, SmallString<4>("lib") + Library + ".a");
+ SmallString<32> Relative("-l");
+ Relative += Library;
+
+ if (getVFS().exists(Shared)) {
+ CmdArgs.push_back(Args.MakeArgString(Shared));
+ } else if (getVFS().exists(Static)) {
+ CmdArgs.push_back(Args.MakeArgString(Static));
+ } else {
+ CmdArgs.push_back(Args.MakeArgString(Relative));
+ }
+ };
+
+ Link("c++");
if (Args.hasArg(options::OPT_fexperimental_library))
- CmdArgs.push_back("-lc++experimental");
+ Link("c++experimental");
break;
+ }
case ToolChain::CST_Libstdcxx:
// Unfortunately, -lstdc++ doesn't always exist in the standard search path;
diff --git a/clang/test/Driver/Inputs/basic_darwin_toolchain/usr/lib/libc++.dylib b/clang/test/Driver/Inputs/basic_darwin_toolchain/usr/lib/libc++.dylib
new file mode 100644
index 0000000000000..e69de29bb2d1d
diff --git a/clang/test/Driver/Inputs/basic_darwin_toolchain/usr/lib/libc++experimental.a b/clang/test/Driver/Inputs/basic_darwin_toolchain/usr/lib/libc++experimental.a
new file mode 100644
index 0000000000000..e69de29bb2d1d
diff --git a/clang/test/Driver/Inputs/basic_darwin_toolchain_static/usr/bin/.keep b/clang/test/Driver/Inputs/basic_darwin_toolchain_static/usr/bin/.keep
new file mode 100644
index 0000000000000..e69de29bb2d1d
diff --git a/clang/test/Driver/Inputs/basic_darwin_toolchain_static/usr/include/c++/v1/.keep b/clang/test/Driver/Inputs/basic_darwin_toolchain_static/usr/include/c++/v1/.keep
new file mode 100644
index 0000000000000..e69de29bb2d1d
diff --git a/clang/test/Driver/Inputs/basic_darwin_toolchain_static/usr/lib/libc++.a b/clang/test/Driver/Inputs/basic_darwin_toolchain_static/usr/lib/libc++.a
new file mode 100644
index 0000000000000..e69de29bb2d1d
diff --git a/clang/test/Driver/Inputs/basic_darwin_toolchain_static/usr/lib/libc++experimental.a b/clang/test/Driver/Inputs/basic_darwin_toolchain_static/usr/lib/libc++experimental.a
new file mode 100644
index 0000000000000..e69de29bb2d1d
diff --git a/clang/test/Driver/darwin-header-search-libcxx.cpp b/clang/test/Driver/darwin-header-search-libcxx.cpp
index cc8ec9ceb89b3..e8985a4e22b2f 100644
--- a/clang/test/Driver/darwin-header-search-libcxx.cpp
+++ b/clang/test/Driver/darwin-header-search-libcxx.cpp
@@ -92,7 +92,7 @@
// CHECK-LIBCXX-SYSROOT_AND_TOOLCHAIN-1: "-internal-isystem" "[[TOOLCHAIN]]/usr/bin/../include/c++/v1"
// CHECK-LIBCXX-SYSROOT_AND_TOOLCHAIN-1-NOT: "-internal-isystem" "[[SYSROOT]]/usr/include/c++/v1"
-// Make sure that using -nostdinc, -nostdinc++ or -nostdlib will drop both the toolchain
+// Make sure that using -nostdinc, -nostdinc++ or -nostdlibinc will drop both the toolchain
// C++ include path and the sysroot one.
//
// RUN: %clang -### %s -fsyntax-only 2>&1 \
@@ -116,7 +116,7 @@
// RUN: -isysroot %S/Inputs/basic_darwin_sdk_usr_cxx_v1 \
// RUN: -stdlib=platform \
// RUN: -nostdinc++ \
-// RUN: | FileCheck -DSYSROOT=%S/Inputs/basic_darwin_sdk_usr \
+// RUN: | FileCheck -DSYSROOT=%S/Inputs/basic_darwin_sdk_usr_cxx_v1 \
// RUN: -DTOOLCHAIN=%S/Inputs/basic_darwin_toolchain \
// RUN: --check-prefix=CHECK-LIBCXX-NOSTDINCXX %s
// CHECK-LIBCXX-NOSTDINCXX: "-cc1"
diff --git a/clang/test/Driver/darwin-link-libcxx.cpp b/clang/test/Driver/darwin-link-libcxx.cpp
new file mode 100644
index 0000000000000..1c4f31b257512
--- /dev/null
+++ b/clang/test/Driver/darwin-link-libcxx.cpp
@@ -0,0 +1,81 @@
+// UNSUPPORTED: system-windows
+
+// Tests to check that we link against the toolchain-provided libc++ built library when it is provided.
+// This is required to prefer the toolchain's libc++ over the system's libc++, which matches the behavior
+// we have for header search paths.
+
+// When libc++.dylib is NOT in the toolchain, we should use -lc++ and fall back to the libc++
+// in the sysroot.
+//
+// (1) Without -fexperimental-library.
+// RUN: %clangxx -### %s 2>&1 \
+// RUN: --target=x86_64-apple-darwin \
+// RUN: -ccc-install-dir %S/Inputs/basic_darwin_toolchain_no_libcxx/usr/bin \
+// RUN: | FileCheck -DTOOLCHAIN=%S/Inputs/basic_darwin_toolchain_no_libcxx \
+// RUN: --check-prefix=CHECK-1 %s
+// CHECK-1: "/usr/bin/ld"
+// CHECK-1: "-lc++"
+// CHECK-1-NOT: "[[TOOLCHAIN]]/usr/lib"
+//
+// (2) With -fexperimental-library.
+// RUN: %clangxx -### %s 2>&1 \
+// RUN: --target=x86_64-apple-darwin \
+// RUN: -ccc-install-dir %S/Inputs/basic_darwin_toolchain_no_libcxx/usr/bin \
+// RUN: -fexperimental-library \
+// RUN: | FileCheck -DTOOLCHAIN=%S/Inputs/basic_darwin_toolchain_no_libcxx \
+// RUN: --check-prefix=CHECK-2 %s
+// CHECK-2: "/usr/bin/ld"
+// CHECK-2: "-lc++" "-lc++experimental"
+// CHECK-2-NOT: "[[TOOLCHAIN]]/usr/lib"
+
+// When we have libc++.dylib in the toolchain, it should be used over the one in the sysroot.
+// There are a few cases worth testing.
+//
+// (1) Without -fexperimental-library.
+// RUN: %clangxx -### %s 2>&1 \
+// RUN: --target=x86_64-apple-darwin \
+// RUN: -ccc-install-dir %S/Inputs/basic_darwin_toolchain/usr/bin \
+// RUN: | FileCheck -DTOOLCHAIN=%S/Inputs/basic_darwin_toolchain \
+// RUN: --check-prefix=CHECK-3 %s
+// CHECK-3: "/usr/bin/ld"
+// CHECK-3: "[[TOOLCHAIN]]/usr/lib/libc++.dylib"
+// CHECK-3-NOT: "-lc++"
+//
+// (2) With -fexperimental-library.
+// RUN: %clangxx -### %s 2>&1 \
+// RUN: --target=x86_64-apple-darwin \
+// RUN: -ccc-install-dir %S/Inputs/basic_darwin_toolchain/usr/bin \
+// RUN: -fexperimental-library \
+// RUN: | FileCheck -DTOOLCHAIN=%S/Inputs/basic_darwin_toolchain \
+// RUN: --check-prefix=CHECK-4 %s
+// CHECK-4: "/usr/bin/ld"
+// CHECK-4: "[[TOOLCHAIN]]/usr/lib/libc++.dylib"
+// CHECK-4: "[[TOOLCHAIN]]/usr/lib/libc++experimental.a"
+// CHECK-4-NOT: "-lc++"
+// CHECK-4-NOT: "-lc++experimental"
+
+// When we have libc++.a in the toolchain instead of libc++.dylib, it should be
+// used over the one in the sysroot.
+//
+// (1) Without -fexperimental-library.
+// RUN: %clangxx -### %s 2>&1 \
+// RUN: --target=x86_64-apple-darwin \
+// RUN: -ccc-install-dir %S/Inputs/basic_darwin_toolchain_static/usr/bin \
+// RUN: | FileCheck -DTOOLCHAIN=%S/Inputs/basic_darwin_toolchain_static \
+// RUN: --check-prefix=CHECK-5 %s
+// CHECK-5: "/usr/bin/ld"
+// CHECK-5: "[[TOOLCHAIN]]/usr/lib/libc++.a"
+// CHECK-5-NOT: "-lc++"
+//
+// (2) With -fexperimental-library.
+// RUN: %clangxx -### %s 2>&1 \
+// RUN: --target=x86_64-apple-darwin \
+// RUN: -ccc-install-dir %S/Inputs/basic_darwin_toolchain_static/usr/bin \
+// RUN: -fexperimental-library \
+// RUN: | FileCheck -DTOOLCHAIN=%S/Inputs/basic_darwin_toolchain_static \
+// RUN: --check-prefix=CHECK-6 %s
+// CHECK-6: "/usr/bin/ld"
+// CHECK-6: "[[TOOLCHAIN]]/usr/lib/libc++.a"
+// CHECK-6: "[[TOOLCHAIN]]/usr/lib/libc++experimental.a"
+// CHECK-6-NOT: "-lc++"
+// CHECK-6-NOT: "-lc++experimental"
diff --git a/clang/test/Driver/experimental-library-flag.cpp b/clang/test/Driver/experimental-library-flag.cpp
index 62b007516897e..0546a09d5518b 100644
--- a/clang/test/Driver/experimental-library-flag.cpp
+++ b/clang/test/Driver/experimental-library-flag.cpp
@@ -18,6 +18,8 @@
// CHECK: -fexperimental-library
// Depending on the stdlib in use, we should (or not) pass -lc++experimental.
-// CHECK-LIBCXX: -lc++experimental
-// CHECK-LIBSTDCXX-NOT: -lc++experimental
-// CHECK-NOSTDLIB-NOT: -lc++experimental
+// Note that we don't check for `-lc++experimental` specifically, since some targets
+// like Darwin pass the path to the library explicitly instead of using `-lx`.
+// CHECK-LIBCXX: c++experimental
+// CHECK-LIBSTDCXX-NOT: c++experimental
+// CHECK-NOSTDLIB-NOT: c++experimental
|
Member
Author
|
As a side effect, this new way of linking against libc++ instead of passing The compiler-rt build is very wrong for doing that, but if we can avoid having to fix it to unblock this fix, that's a good thing. |
Contributor
Sorry it's not the the |
Contributor
|
I'm still not sure this is a good idea, if there ever was a XcodeDefault.xctoolchain/usr/lib/libc++.dylib it wouldn't be linkable from anything outside of Xcode (its |
Member
Author
This whole change basically has nothing to do with Xcode or the way we distribute libc++ on Apple platforms as a system library. It's all about unbreaking the toolchain we produce in upstream builds of Clang and libc++. On Apple platforms, libc++ may be shipped in two different ways:
So, why is that more of a problem now than it was in the past? Simply because we've introduced more differences between the So, again, this has nothing to do with the way we ship libc++ within Xcode. In the Xcode case, there is no libc++ in the toolchain, so we always fall back to the SDK (for headers and for linking).
So, hopefully that is made clear by the above, but there is no intention to ever have |
Contributor
|
Oh I see, and I was missing the part in |
ian-twilightcoder
approved these changes
Dec 4, 2025
cachemeifyoucan
approved these changes
Dec 4, 2025
Collaborator
cachemeifyoucan
left a comment
cachemeifyoucan
left a comment
There was a problem hiding this comment.
This version LGTM
Member
Author
|
Thanks for the reviews. For information, I'm currently investigating some new failures I'm seeing when doing a bootstrapping build. The compiler-rt build is complaining about something new I wasn't seeing before (but I did a clean reinstall of my system in between, so some stuff may have changed). Before I land this, I'll also want to make sure I understand the RPATH story for the toolchain we're building upstream -- since it's the first time we'll actually be linking against the |
Member
Author
|
Okay, I got the compiler-rt build to stop complaining. I think something that was previously a warning in I'm investigating the rpath situation now: So Now, when we build an executable using that toolchain: First, I can see that the executable references the rpath-relative However, when I run the executable, it fails at load time because it can't find the dylib in question: This all makes sense: we haven't told anyone what rpath the executable should be using. So, if we now tell it to use the right rpath when compiling: Now it's happy. So, I believe the right thing to do here is for whoever is actually installing the toolchain into its final destination to either:
I believe (2) is what everybody shipping a toolchain is already doing. I'm mostly writing this down to leave breadcrumbs of my reasoning. @tstellar, can you validate that we're OK with producing a toolchain that contains |
Member
Author
|
Alright, I've tested with a slightly modified Homebrew formula (they change the installation directory of |
Member
Author
|
Note that it's possible that landing this patch is going to expose places where we were previously using the SDK libc++ headers when we really intended to be using the toolchain libc++ headers. The failure mode for that would be that a program is compiled against SDK headers, and hence makes references to stuff that's only present in Apple's system Without proper CI on Apple platforms (🥲), I don't know how to shake those out, so I guess we'll have to land this and be ready to fix stuff forward, and potentially revert. |
Member
Author
|
Just for posterity, here are my changes to the Homebrew formula: diff --git a/Formula/l/llvm.rb b/Formula/l/llvm.rb
index 74373c08297..49c174df36f 100644
--- a/Formula/l/llvm.rb
+++ b/Formula/l/llvm.rb
@@ -9,6 +9,12 @@ class Llvm < Formula
url "https://github.com/llvm/llvm-project/releases/download/llvmorg-21.1.7/llvm-project-21.1.7.src.tar.xz"
sha256 "e5b65fd79c95c343bb584127114cb2d252306c1ada1e057899b6aacdd445899e"
+ # Apply https://github.com/llvm/llvm-project/pull/170303
+ patch do
+ url "https://github.com/llvm/llvm-project/pull/170303.diff"
+ # sha256 ""
+ end
+
# Fix triple config loading for clang-cl
# https://github.com/llvm/llvm-project/pull/111397
patch do
@@ -168,16 +174,13 @@ class Llvm < Formula
args << "-DFFI_INCLUDE_DIR=#{macos_sdk}/usr/include/ffi"
args << "-DFFI_LIBRARY_DIR=#{macos_sdk}/usr/lib"
- libcxx_install_libdir = lib/"c++"
libunwind_install_libdir = lib/"unwind"
- libcxx_rpaths = [loader_path, rpath(source: libcxx_install_libdir, target: libunwind_install_libdir)]
+ libcxx_rpaths = [loader_path, rpath(source: lib, target: libunwind_install_libdir)]
args << "-DLLVM_BUILD_LLVM_C_DYLIB=ON"
args << "-DLLVM_ENABLE_LIBCXX=ON"
args << "-DLIBCXX_PSTL_BACKEND=libdispatch"
- args << "-DLIBCXX_INSTALL_LIBRARY_DIR=#{libcxx_install_libdir}"
args << "-DLIBUNWIND_INSTALL_LIBRARY_DIR=#{libunwind_install_libdir}"
- args << "-DLIBCXXABI_INSTALL_LIBRARY_DIR=#{libcxx_install_libdir}"
runtimes_cmake_args << "-DCMAKE_INSTALL_RPATH=#{libcxx_rpaths.join("|")}"
# Disable builds for OSes not supported by the CLT SDK.
I'll create a patch to propose these changes once this change has settled down. |
Collaborator
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/10/builds/18578 Here is the relevant piece of the build log for the reference |
Collaborator
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/11/builds/29386 Here is the relevant piece of the build log for the reference |
Contributor
|
Hi! It seems this PR breaks bots. Could you please take a look? Thanks! |
Contributor
|
We are seeing test failures on Failed task: https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-host-linux-x64/b8696300887931519761/overview Could you revert your change and fix it please? |
Collaborator
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/140/builds/35231 Here is the relevant piece of the build log for the reference |
Collaborator
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/224/builds/206 Here is the relevant piece of the build log for the reference |
Member
Author
|
Ack, let's follow up on #170912 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When libc++ is bootstrapped with clang, the resulting clang uses the just-built libc++ headers from /bin/../include/c++/v1. However, before this patch, clang would still use the system-provided libc++.dylib (usually in the Apple SDK) because it would fail to add the corresponding linker flag to find the just-built libc++. After this patch, Clang will instead link against the toolchain provided
libc++.dylibin<install>/libif it exists, which will result in programs being linked against corresponding libc++ headers and dylib.Fixes #77653
rdar://107060541