[compiler-rt lsan] lipo error when building llvm 16.0.4 from source

[susugagalala]

I encountered the following build error when building LLVM 16.0.4 on a macOS x86_64 host. The source code was taken from here:

https://github.com/llvm/llvm-project/archive/refs/tags/llvmorg-16.0.4.tar.gz

fatal error: /Library/Developer/CommandLineTools/usr/bin/lipo: /var/folders/gn/s0ng0p2x0lvcknxk20tp3nsc0000gp/T/lsan-0f8184/lsan-x86_64.out and /var/folders/gn/s0ng0p2x0lvcknxk20tp3nsc0000gp/T/lsan-2300a3/lsan-x86_64h.out have the same architectures (x86_64) and can't be in the same fat output file
clang++: error: lipo command failed with exit code 1 (use -v to see invocation)
make[2]: *** [lib/clang/16/lib/darwin/libclang_rt.lsan_osx_dynamic.dylib] Error 1
make[1]: *** [projects/compiler-rt/lib/lsan/CMakeFiles/clang_rt.lsan_osx_dynamic.dir/all] Error 2
make: *** [all] Error 2

[hoyhoy]

I just hit a similar problem using 16.0.6 to compile llvm 17 with XCode 15's lipo. Is there some way to turn off x86_64h? I don't need it.

sanitizer_allocator-x86_64.out and /var/folders/sg/by4ymb_1491658nz5rdt1k940000gn/T/sanitizer_allocator-06ef06/sanitizer_allocator-x86_64h.out have the same architectures (x86_64) and can't be in the same fat output file
clang-16: error: lipo command failed with exit code 1 (use -v to see invocation)
[3439/6947] Building CXX object projects/compiler-rt/lib/lsan/CMakeFiles/RTLSanCommon.osx.dir/lsan_common.cpp.o
ninja: build stopped: subcommand failed.

[gbaraldi]

Did any of you folks figure this out? I see this with ubsan as well, when crosscompiling to x86_64-darwin with clang+lld

[hoyhoy]

Did any of you folks figure this out? I see this with ubsan as well, when crosscompiling to x86_64-darwin with clang+lld

I ended up using the latest XCode to compile Clang 17.0.1 on macOS 14 and that worked for me. I just recompiled Clang 17.0.3 with Clang 17.0.1 and that worked as well.

[DavidSpickett]

I have used the CMake setting COMPILER_RT_DEFAULT_TARGET_ONLY in the past, to disable building 32 and 64 bit on x86 machines that didn't have 32 bit libraries.

That might work here, since x86_64h seems to be treated as an architecture variant.

[hoyhoy]

Just hit this again. COMPILER_RT_DEFAULT_TARGET_ONLY doesn't disable x86_64h. You have to manually remove it from builtin-config-ix.cmake.

lvm-lipo: error: /var/folders/sg/by4ymb_1491658nz5rdt1k940000gn/T/sanitizer_allocator-4d45c0/sanitizer_allocator-x86_64.out and /var/folders/sg/by4ymb_1491658nz5rdt1k940000gn/T/sanitizer_allocator-a6fe88/sanitizer_allocator-x86_64h.out have the same architecture x86_64 and therefore cannot be in the same universal binary
clang++: error: lipo command failed with exit code 1 (use -v to see invocation)

[sztomi]

You have to manually remove it from builtin-config-ix.cmake

I'm also hitting this, but I don't think removing x86_64h is the right move. If anything, removing x86_64 makes more sense. No Apple hardware since 2013 is sold without haswell extensions and it's highly unlikely that your developers would use such hardware for work.

[sztomi]

For what its worth, I just verified that commenting out the x86_64 arch (and leaving only x86_64h) works fine. I'm confused why this happens in the first place because both the logic for this error in lipo (and llvm-lipo) is old code, and so is the CMake script selecting the architectures. The sample 2-stage Apple CMake caches don't produce these errors, but they aren't using PGO either. I'm certain that the issue can be worked out by minimizing the CMake flags until it no longer repros, but I'm OK with this workaround.

[hoyhoy]

It's still a problem in 18.1.3. Thanks for the recommendation on X86_64h. I'm actually getting a crash in lldb as well. Now I'm wondering if it's because I'm using the old X86_64 architecture flag.