[Lldb-commits] [lldb] [lldb] Change most tests to build with system libc++ on Darwin (PR #190034)

[Alex Langford via lldb-commits]

https://github.com/bulbazord created https://github.com/llvm/llvm-project/pull/190034

Today, on Darwin platforms, almost every test binary in our test suite loads two copies of libc++, libc++abi, and libunwind. This is because each of the test binaries explicitly link against a just-built libc++ (which is explicitly required on Darwin right now) but we don't take the correct steps to replace the system libc++. Doing so is unnecessary and potentially error-prone, so most tests should link against the system libc++ where possible.

Background:
The lldb test suite has a collection of tests that rely on libc++ explicitly. The two biggest categories are data formatter tests (which make sure that we can correctly display values for std types) and import-std-module tests (which test that we can import the libc++ std module). To make sure these tests are run, we require a just-built libc++ to be used.

All of the test binaries link against the just-built libc++, so it gets loaded. However, when any system library tries to load libc++, it attempts to load the system one. dyld checks loaded libraries against the request to load a new one using the full path, meaning anyone linking against `/usr/lib/libc++.1.dylib` will get it no matter what other libc++ dylib is already loaded.

The proper way to handle this is using `DYLD_LIBRARY_PATH`, which switches dyld to checking the leaf name of a dylib instead of the full path. In theory this works, but we run into an issue where the system libc++ has additional symbols and many system libraries fail to load. Louis Dionne added stubs in libc++abi for these missing symbols, meaning it would be possible to make this scenario work. This may be useful for the existing libc++ tests.

>From 2ed4b8de3585044f3731e4f10b313a43d0a03b2f Mon Sep 17 00:00:00 2001
From: Alex Langford <alangford at apple.com>
Date: Wed, 1 Apr 2026 12:29:31 -0700
Subject: [PATCH] [lldb] Change most tests to build with system libc++ on
 Darwin

Today, on Darwin platforms, almost every test binary in our test suite
loads two copies of libc++, libc++abi, and libunwind. This is because
each of the test binaries explicitly link against a just-built libc++
(which is explicitly required on Darwin right now) but we don't take the
correct steps to replace the system libc++. Doing so is unnecessary and
potentially error-prone, so most tests should link against the system
libc++ where possible.

Background:
The lldb test suite has a collection of tests that rely on
libc++ explicitly. The two biggest categories are data formatter tests
(which make sure that we can correctly display values for std types) and
import-std-module tests (which test that we can import the libc++ std
module). To make sure these tests are run, we require a just-built
libc++ to be used.

All of the test binaries link against the just-built libc++, so it
gets loaded. However, when any system library tries to load libc++, it
attempts to load the system one. dyld checks loaded libraries against
the request to load a new one using the full path, meaning anyone
linking against `/usr/lib/libc++.1.dylib` will get it no matter what
other libc++ dylib is already loaded.

The proper way to handle this is using `DYLD_LIBRARY_PATH`, which
switches dyld to checking the leaf name of a dylib instead of the full
path. In theory this works, but we run into an issue where the system
libc++ has additional symbols and many system libraries fail to load.
Louis Dionne added stubs in libc++abi for these missing symbols, meaning
it would be possible to make this scenario work. This may be useful for
the existing libc++ tests.
---
 .../Python/lldbsuite/test/make/Makefile.rules | 29 ++++++++++++-------
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
index f7f6e48f71e55..6c197a2317bf7 100644
--- a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
+++ b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
@@ -441,18 +441,25 @@ ifeq (1, $(USE_SYSTEM_STDLIB))
 endif
 
 ifeq (,$(filter 1, $(USE_LIBSTDCPP) $(USE_LIBCPP) $(USE_SYSTEM_STDLIB)))
-  # If no explicit C++ library request was made, but we have paths to a custom libcxx, use
-  # them.  Otherwise, use the system library by default.
-  ifneq ($(and $(LIBCPP_INCLUDE_DIR), $(LIBCPP_LIBRARY_DIR)),)
-    CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem $(LIBCPP_INCLUDE_DIR)
-    ifneq "$(LIBCPP_INCLUDE_TARGET_DIR)" ""
-      CXXFLAGS += -cxx-isystem $(LIBCPP_INCLUDE_TARGET_DIR)
-    endif
-
-	# If `-nostdlib++` is not passed, clang will link to the system's stdlib.
-    LDFLAGS += -nostdlib++ -L$(LIBCPP_LIBRARY_DIR) -Wl,-rpath,$(LIBCPP_LIBRARY_DIR) -lc++
-  else
+  ifeq "$(OS)" "Darwin"
+    # If no explicit C++ library request was made, default to the system
+    # libc++. Testing a custom libc++ correctly on apple platforms is difficult
+    # and the apppropriate use cases are limited.
     USE_SYSTEM_STDLIB := 1
+  else
+    # If no explicit C++ library request was made, but we have paths to a custom libcxx, use
+    # them.  Otherwise, use the system library by default.
+    ifneq ($(and $(LIBCPP_INCLUDE_DIR), $(LIBCPP_LIBRARY_DIR)),)
+      CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem $(LIBCPP_INCLUDE_DIR)
+      ifneq "$(LIBCPP_INCLUDE_TARGET_DIR)" ""
+        CXXFLAGS += -cxx-isystem $(LIBCPP_INCLUDE_TARGET_DIR)
+      endif
+
+    # If `-nostdlib++` is not passed, clang will link to the system's stdlib.
+      LDFLAGS += -nostdlib++ -L$(LIBCPP_LIBRARY_DIR) -Wl,-rpath,$(LIBCPP_LIBRARY_DIR) -lc++
+    else
+      USE_SYSTEM_STDLIB := 1
+    endif
   endif
 endif