Undefined reference issues when mixing Homebrew LLVM 21.1.0 with system libc++

[chrismile]

brew gist-logs <formula> link OR brew config AND brew doctor output

The output below is from the GitHub actions reproducer.

brew config:

HOMEBREW_VERSION: 4.6.7
ORIGIN: https://github.com/Homebrew/brew
HEAD: 02947ea4edbdef5fcce9ee57fa289547f4d096c9
Last commit: 4 days ago
Branch: stable
Core tap JSON: 28 Aug 23:14 UTC
Core cask tap JSON: 28 Aug 23:14 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: ["--no-quarantine"]
HOMEBREW_COLOR: set
HOMEBREW_FORBID_PACKAGES_FROM_PATHS: set
HOMEBREW_MAKE_JOBS: 3
HOMEBREW_NO_AUTO_UPDATE: set
HOMEBREW_NO_INSTALL_CLEANUP: set
Homebrew Ruby: 3.4.5 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.4.5/bin/ruby
CPU: 3-core 64-bit dunno
Clang: 16.0.0 build 1600
Git: 2.50.1 => /opt/homebrew/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 15.5-arm64
CLT: 16.4.0.0.1.1747106510
Xcode: 16.0 => /Applications/Xcode_16.app/Contents/Developer
Rosetta 2: false


brew doctor:

Your system is ready to brew.

Verification

• My brew doctor output says Your system is ready to brew. and am still able to reproduce my issue.
• I ran brew update and am still able to reproduce my issue.
• I have resolved all warnings from brew doctor and that did not fix my problem.
• I searched for recent similar issues at https://github.com/Homebrew/homebrew-core/issues?q=is%3Aissue and found no duplicates.
• My issue is not about a failure to build a formula from source.

What were you trying to do (and why)?

LLVM 21.1.0 seems to have made some changes that make sources compiled with its headers incompatible with older versions of libc++.
See e.g.: llvm/llvm-project#155606

I run into this issue when using clang++ from the Homebrew llvm formula to compile a shared library using std::hash. I have created a small reproducer here using GitHub actions: https://github.com/chrismile/ActionsTestRepo4

I assume that this might be fixable with LDFLAGS="-L/opt/homebrew/opt/llvm/lib/c++", as the library is then linked with the correct version of libc++. But when installing the llvm formula, this message is explicitly printed:

To use the bundled libc++ please use the following LDFLAGS:
  LDFLAGS="-L/opt/homebrew/opt/llvm/lib/c++ -L/opt/homebrew/opt/llvm/lib/unwind -lunwind"
NOTE: You probably want to use the libunwind and libc++ provided by macOS unless you know what you're doing.

I think the notice that one should use "libc++ provided by macOS unless you know what you're doing" is problematic. There seems to be no guarantee that an app compiled with the LLVM version from Homebrew will work with the system libc++.

What happened (include all command output)?

Compilation stage of the reproducer:

/opt/homebrew/opt/llvm/bin/clang++ -Dtestlib_EXPORTS  -O3 -DNDEBUG -arch arm64 -fPIC -MD -MT CMakeFiles/testlib.dir/src/Main.cpp.o -MF CMakeFiles/testlib.dir/src/Main.cpp.o.d -o CMakeFiles/testlib.dir/src/Main.cpp.o -c /Users/runner/work/ActionsTestRepo4/ActionsTestRepo4/src/Main.cpp

Linking stage of the reproducer:

Undefined symbols for architecture arm64:
/opt/homebrew/opt/llvm/bin/clang++ -O3 -DNDEBUG -arch arm64 -dynamiclib -Wl,-headerpad_max_install_names -o libtestlib.dylib -install_name @rpath/libtestlib.dylib CMakeFiles/testlib.dir/src/Main.cpp.o
  "std::__1::__hash_memory(void const*, unsigned long)", referenced from:
[...]

What did you expect to happen?

That when using the recommended options, linking does not fail for a relatively simple program.

Step-by-step reproduction instructions (by running brew commands)

Reproducer app provided at https://github.com/chrismile/ActionsTestRepo4.

[q-p]

You can set _LIBCPP_INTRODUCED_IN_LLVM_21 to 0 in llvm@21/include/c++/v1/__configuration/availability.h.

That's probably something the formula should do by default (or not link against the system libc++ alternatively).

[chrismile]

That's probably something the formula should do by default (or not link against the system libc++ alternatively).

I agree. It's good to have a workaround, but of course the underlying issue should still be fixed in some way in the formula.

[chrismile]

I attempted to fix the issue by setting _LIBCPP_INTRODUCED_IN_LLVM_21 to 0 in the patch at main...chrismile:homebrew-core:fix-llvm21, but for whatever reason, HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source llvm fails for me on my Linux system (I have no macOS system for testing) with the following error.

[1928/2774] /var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/llvm/build/bin/clang++ --target=x86_64-unknown-linux-gnu -DLIBCXX_BUILDING_LIBCXXABI -DLIBC_NAMESPACE=__llvm_libc_common_utils -D_LIBCPP_BUILDING_LIBRARY -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D_LIBCPP_LINK_PTHREAD_LIB -D_LIBCPP_LINK_RT_LIB -D_LIBCPP_REMOVE_TRANSITIVE_INCLUDES -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/libcxx/src -I/var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/llvm/build/include/c++/v1 -I/var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/libcxxabi/include -I/var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/cmake/Modules/../../libc -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -ffile-prefix-map=/var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/llvm/build/runtimes/runtimes-bins=../../../../ -ffile-prefix-map=/var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/=. -no-canonical-prefixes -O3 -DNDEBUG -std=c++23 -fPIC -faligned-allocation -nostdinc++ -fvisibility-inlines-hidden -fvisibility=hidden -fsized-deallocation -Wall -Wextra -Wnewline-eof -Wshadow -Wwrite-strings -Wno-unused-parameter -Wno-long-long -Werror=return-type -Wextra-semi -Wundef -Wunused-template -Wformat-nonliteral -Wzero-length-array -Wdeprecated-redundant-constexpr-static-def -Wno-nullability-completeness -Wno-user-defined-literals -Wno-covered-switch-default -Wno-suggest-override -Wno-error -fdebug-prefix-map=/var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/llvm/build/include/c++/v1=/var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/libcxx/include -MD -MT libcxx/src/CMakeFiles/cxx_shared.dir/functional.cpp.o -MF libcxx/src/CMakeFiles/cxx_shared.dir/functional.cpp.o.d -o libcxx/src/CMakeFiles/cxx_shared.dir/functional.cpp.o -c /var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/libcxx/src/functional.cpp
/var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/llvm/build/bin/clang++ --target=x86_64-unknown-linux-gnu -DLIBCXX_BUILDING_LIBCXXABI -DLIBC_NAMESPACE=__llvm_libc_common_utils -D_LIBCPP_BUILDING_LIBRARY -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D_LIBCPP_LINK_PTHREAD_LIB -D_LIBCPP_LINK_RT_LIB -D_LIBCPP_REMOVE_TRANSITIVE_INCLUDES -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/libcxx/src -I/var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/llvm/build/include/c++/v1 -I/var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/libcxxabi/include -I/var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/cmake/Modules/../../libc -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -ffile-prefix-map=/var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/llvm/build/runtimes/runtimes-bins=../../../../ -ffile-prefix-map=/var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/=. -no-canonical-prefixes -O3 -DNDEBUG -std=c++23 -fPIC -faligned-allocation -nostdinc++ -fvisibility-inlines-hidden -fvisibility=hidden -fsized-deallocation -Wall -Wextra -Wnewline-eof -Wshadow -Wwrite-strings -Wno-unused-parameter -Wno-long-long -Werror=return-type -Wextra-semi -Wundef -Wunused-template -Wformat-nonliteral -Wzero-length-array -Wdeprecated-redundant-constexpr-static-def -Wno-nullability-completeness -Wno-user-defined-literals -Wno-covered-switch-default -Wno-suggest-override -Wno-error -fdebug-prefix-map=/var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/llvm/build/include/c++/v1=/var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/libcxx/include -MD -MT libcxx/src/CMakeFiles/cxx_shared.dir/functional.cpp.o -MF libcxx/src/CMakeFiles/cxx_shared.dir/functional.cpp.o.d -o libcxx/src/CMakeFiles/cxx_shared.dir/functional.cpp.o -c /var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/libcxx/src/functional.cpp
/var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/libcxx/src/functional.cpp:15:32: error: out-of-line definition of 'what' does not match any declaration in 'std::bad_function_call'
/var/tmp/llvm-20250904-186192-jdtnh9/llvm-project-21.1.0.src/libcxx/src/functional.cpp:17:8: error: conflicting types for '__hash_memory'
2 errors generated.

The error regarding __hash_memory would indicate to me that this is not the right way forward. Probably someone with more LLVM or brew experience will need to look at the fix. Maybe the header can only be adapted after LLVM was built.

[IsaacMarovitz]

Running into this issue also and it's proving pretty disastrous when building many projects.