regression compiling cmake on macOS due to __hash_memory link errors

[seanm]

I have bisected a link error I'm getting to 17d0569.

One commit before that, all is well. Starting with that commit, I get this link error:

Undefined symbols for architecture arm64:
  "std::__1::__hash_memory(void const*, unsigned long)", referenced from:
      unsigned long std::__1::__do_string_hash[abi:se210000]<char const*>(char const*, char const*) in libCMakeLib.a[16](cmBinUtilsLinuxELFLinker.cxx.o)

This occurs using my own build of Clang (on arm64 macOS 26 beta, and x86_64 macOS 13) then using that to build CMake (and other projects too).

This is similar to #133304 which was closed as a duplicate of #79933 but that was close as "not planned" because basically "linux needs to add availability markups to libc++" but my issue is on macOS, where such availability markups do exist IIUC. So I presume this is different.

@philnik777 @ldionne maybe you have some insight here? Thanks.

[philnik777]

Could you give a bit more information? How are you building Clang? Which libc++ headers do you use? Do you possibly have libc++ headers from homebrew? This looks to me like you're not getting the availability markups.

[Voldemat]

Encountered same issue on latest tag llvmorg-21.1.0, I`m on macos 15.4 m1
here is compilation commands:

cmake -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra" \
-DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libunwind" \
-DCMAKE_OSX_SYSROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk \
-DCMAKE_BUILD_TYPE=Release \
-DLLVM_TARGETS_TO_BUILD="ARM;AArch64" \
-DCMAKE_CXX_STANDARD=20 \
-DDEFAULT_SYSROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk \
-G "Unix Makefiles" ../llvm \
make -j 16

After that I try to compile this example program:

#include <string>
#include <unordered_map>

int main() {
    const auto& a = std::unordered_map<std::string, std::string>{
        {"hello", "write"}
    };
    return 0;
}

clang++ -v check.cpp -o main
clang version 21.1.0 (https://github.com/llvm/llvm-project.git 3623fe661ae35c6c80ac221f14d85be76aa870f1)
Target: arm64-apple-darwin24.4.0
Thread model: posix
InstalledDir: /Users/vladimir/code/opensource/llvm-project/build/bin
"/Users/vladimir/code/opensource/llvm-project/build/bin/clang-21" -cc1 -triple arm64-apple-macosx15.0.0 -Wundef-prefix=TARGET_OS_ -Werror=undef-prefix -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -dumpdir main- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name check.cpp -mrelocation-model pic -pic-level 2 -mframe-pointer=non-leaf -ffp-contract=on -fno-rounding-math -funwind-tables=1 -fcompatibility-qualified-id-block-type-checking -fvisibility-inlines-hidden-static-local-var -fbuiltin-headers-in-system-modules -fdefine-target-os-macros -enable-tlsdesc -target-cpu apple-m1 -target-feature +v8.4a -target-feature +aes -target-feature +altnzcv -target-feature +ccdp -target-feature +ccpp -target-feature +complxnum -target-feature +crc -target-feature +dotprod -target-feature +flagm -target-feature +fp-armv8 -target-feature +fp16fml -target-feature +fptoint -target-feature +fullfp16 -target-feature +jsconv -target-feature +lse -target-feature +neon -target-feature +pauth -target-feature +perfmon -target-feature +predres -target-feature +ras -target-feature +rcpc -target-feature +rdm -target-feature +sb -target-feature +sha2 -target-feature +sha3 -target-feature +specrestrict -target-feature +ssbs -target-abi darwinpcs -debugger-tuning=lldb -fdebug-compilation-dir=/Users/vladimir/code/opensource/llvm-project/build -target-linker-version 1167.5 -v -fcoverage-compilation-dir=/Users/vladimir/code/opensource/llvm-project/build -resource-dir /Users/vladimir/code/opensource/llvm-project/build/lib/clang/21 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -internal-isystem /Users/vladimir/code/opensource/llvm-project/build/bin/../include/c++/v1 -internal-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include -internal-isystem /Users/vladimir/code/opensource/llvm-project/build/lib/clang/21/include -internal-externc-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -internal-iframework /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks -internal-iframework /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/SubFrameworks -internal-iframework /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/Library/Frameworks -fdeprecated-macro -ferror-limit 19 -fmessage-length=143 -stack-protector 1 -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fcxx-exceptions -fexceptions -fmax-type-align=16 -fcolor-diagnostics -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /var/folders/gt/n64rgjdx27lfbwflrwm5xr3w0000gn/T/check-b54798.o -x c++ check.cpp
clang -cc1 version 21.1.0 based upon LLVM 21.1.0 default target arm64-apple-darwin24.4.0
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/SubFrameworks"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/Users/vladimir/code/opensource/llvm-project/build/bin/../include/c++/v1
/Users/vladimir/code/opensource/llvm-project/build/lib/clang/21/include
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.
"/usr/bin/ld" -demangle -lto_library /Users/vladimir/code/opensource/llvm-project/build/lib/libLTO.dylib -no_deduplicate -dynamic -arch arm64 -platform_version macos 15.0.0 15.0.0 -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -mllvm -enable-linkonceodr-outlining -o main /var/folders/gt/n64rgjdx27lfbwflrwm5xr3w0000gn/T/check-b54798.o -lc++ -lSystem
Undefined symbols for architecture arm64:
 "std::__1::__hash_memory(void const*, unsigned long)", referenced from:
     unsigned long std::__1::__do_string_hash[abi:ne210100]<char const*>(char const*, char const*) in check-b54798.o
ld: symbol(s) not found for architecture arm64
clang++: error: linker command failed with exit code 1 (use -v to see invocation)

[seanm]

How are you building Clang?

mkdir build
cd build
CC=/usr/bin/cc CXX=/usr/bin/c++ /Applications/CMake.app/Contents/bin/cmake -G Ninja -Wno-dev -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_C_FLAGS='-w' -DCMAKE_CXX_FLAGS='-w' -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_PROJECTS='clang;clang-tools-extra' -DLLVM_ENABLE_RUNTIMES='libcxx;libcxxabi;libunwind;compiler-rt' -DLLVM_CREATE_XCODE_TOOLCHAIN=ON -DLLVM_BUILD_TOOLS=ON -DCLANG_INCLUDE_DOCS=OFF -DCLANG_INCLUDE_TESTS=OFF -DLLVM_INCLUDE_BENCHMARKS=OFF -DLLVM_INCLUDE_DOCS=OFF -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_INCLUDE_TESTS=OFF -DLLVM_ENABLE_LIBXML2=OFF -DCMAKE_INSTALL_PREFIX=/Users/sean/external/llvm-install ../llvm
ninja install

The /usr/bin/cc is from Xcode.

Which libc++ headers do you use?

I don't know. How do I determine that? I didn't do anything to specify any explicitly.

Do you possibly have libc++ headers from homebrew?

The macOS 13 Mac has brew, but the macOS 26 Mac does not (though it has MacPorts).

---

@Voldemat thanks for figuring out a minimal case. I repro with that:

% xcrun /Users/sean/external/llvm-install/bin/clang++ test.cxx
ld: Undefined symbols:
  std::__1::__hash_memory(void const*, unsigned long), referenced from:
      unsigned long std::__1::__do_string_hash[abi:se220000]<char const*>(char const*, char const*) in test-c5ddd5.o
clang++: error: linker command failed with exit code 1 (use -v to see invocation)

[ldionne]

The problem is that you are using the LLVM 21 headers provided by your build from sources, but you're linking against the system-provided libc++.1.dylib, which is older and doesn't provide that symbol. Clang should arguably link against the just-built libc++ as well, but it doesn't do that out of the box. There is an issue about doing just that (with lots of discussion on it): #77653.

Closing as a duplicate.

[seanm]

@ldionne thanks for your reply, could you elaborate though?

The problem is that you are using the LLVM 21 headers provided by your build from sources, but you're linking against the system-provided libc++.1.dylib

OK, but how am I doing ether of those? The clang invocation is just:

xcrun /Users/sean/external/llvm-install/bin/clang++ test.cxx

Is it the presence of xcrun that is making me use the system-provided libc++.1.dylib?

What is making me use the headers from my own build?

What incantation do I need to make the clang I've built work?

Thanks.

[ldionne]

@ldionne thanks for your reply, could you elaborate though?

The problem is that you are using the LLVM 21 headers provided by your build from sources, but you're linking against the system-provided libc++.1.dylib

OK, but how am I doing ether of those? The clang invocation is just:

That's the behavior that Clang has out of the box, basically. You're not doing anything wrong, IMO this is a bug in Clang.

xcrun /Users/sean/external/llvm-install/bin/clang++ test.cxx

Is it the presence of xcrun that is making me use the system-provided libc++.1.dylib?

No. xcrun sets the SDKROOT environment variable, and then Clang picks that up and uses it as a sysroot (roughly equivalent to passing -isysroot <SDKROOT>.

What is making me use the headers from my own build?

By default, Clang will check (in order):
1a. The include/c++/v1 relative to Clang's executable
2a. The include/c++/v1 relative to the sysroot (which for you is SDKROOT since you use xcrun)

The exact logic is here: https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/Darwin.cpp#L2748-L2760

Now, in your case, since Clang finds include/c++/v1 at <clang-executable-folder>/../include/c++/v1, it stops at (1a) and uses that, which corresponds to your just-built libc++ headers.

The problem is that it doesn't do the same thing when figuring out which library to link against. For linking, it simply uses the one from the sysroot, without checking if you might have a just-built libc++ available relative to the Clang executable. In other words, you probably have both:
1b. <clang-executable-folder>/../lib/libc++.1.dylib
2b. SDKROOT/usr/lib/libc++.1.dylib

But unlike for the header search path logic, here it goes straight to (2b) and ignores (1b).

That way, you end up mixing (1a) with (2b), when what you want is (1a) with (2a).

What incantation do I need to make the clang I've built work?

It sucks, but I think that adding -L <clang-executable-folder>/../lib should fix your issue. That being said, you'll also need to make sure that the executables you produce are able to find <clang-executable-folder>/../lib/libc++.1.dylib at runtime, which might require setting up some rpaths or playing with DYLD_LIBRARY_PATH.

[Voldemat]

Is it possible to add some default compile options to clang when compiling? I pocked around in cmake files but didn`t found anything like that, I think having cmake variable that embeds set of default options inside compiler would be extremely useful in such cases.

[ldionne]

I'm not aware of anything that allows doing that. IMO we should just fix the compiler so it does the right thing out of the box.