I’ve been building Clang from source and using it to compile things on my host system (macOS, x86_64). Now I’d like to build llvm/clang/libc++ so I can create iOS apps as well. I tried:
That last -D option was a guess. I get the error below.
Is there a CMake invocation that will allow me to build:
A clang that can compile binaries for macOS and iOS devices (x86, arm)
The libraries like libc++.a that I can statically link to deploy apps to those devices.
Thank you.
CMake Error at runtimes/CMakeLists.txt:54 (message):
compiler-rt for Darwin builds for all platforms and architectures using a
single configuration. Specify only a single darwin triple (e.g.
x86_64-apple-darwin) in your targets list (and not a triple for a specific
platform such as macos). You can use variables such as
COMPILER_RT_ENABLE_IOS and DARWIN_ios_ARCHS to control the specific
platforms and architectures to build. Set RUNTIMES_BUILD_ALLOW_DARWIN to
allow a single darwin triple.
Call Stack (most recent call first):
runtimes/CMakeLists.txt:438 (check_apple_target)
Just reading that message it seems that you should give one triple to RUNTIME_TARGETS and the result will be all possible configurations for Darwin. Is that not what you get when you try that?
I think it’s basically saying that the Darwin build bucks the trend of the runtimes build, which is for the user to specify individual targets. So you must opt into that behaviour for Darwin if you want it (and here you don’t want to opt in).
If I use one triple there and try the other settings in the error message, I get something that builds, but I still don’t see a libc++ anywhere built for ARM. It’s tough to just guess, because it takes about an hour to build this on my laptop.
I think you do not want -DRUNTIMES_BUILD_ALLOW_DARWIN=ON because that’s causing it to build just for the single triple, as opposed to all supported Darwin architectures.
I think those error messages were about the compiler-rt component, which is not libc++. I did get multi-architecture builds of what I think are the compiler-rt libraries. So maybe all I need now is to find out how to do the same thing with libc++.
% ls build/lib/clang/17/lib/darwin/
libclang_rt.asan_ios_dynamic.dylib
libclang_rt.asan_iossim_dynamic.dylib
libclang_rt.asan_osx_dynamic.dylib
...
I tried rerunning my command above with -DLLVM_RUNTIME_TARGETS="arm64-apple-darwin" and it ended up making an libc++ that looks like it’s for ARM, but leads to errors like the one below.
I’m going to stop guessing now, because every time I try something, it’s hour of CPU fans on my MacBook, rebuilding everything.
ld: in /Dev/llvm-project/build/lib/libc++experimental.a(memory_resource.cpp.o), building for iOS,
but linking in object file built for macOS,
file '/Dev/llvm-project/build/lib/libc++experimental.a' for architecture arm64
IIRC CMake currently warns about using libcxx in LLVM_ENABLE_PROJECTS, but it works, so I’m not changing that until it breaks. I don’t know if that warning is intended to be shown on Darwin.
Not all of these will be relevant to everyone and frankly, some of this is probably legacy from our point of view as well. Make sure to use a fresh build dir when changing these options. Let me know how it goes, happy to help further.
Thanks! Before I try this, let me try to understand better. You don’t have ‘clang’ in LLVM_ENABLE_PROJECTS. Did you run another build first to create clang, and you’ve got your PATH set somehow to use that new clang for this build here with compiler-rt;libcxx?
And you also didn’t use LLVM_RUNTIME_TARGETS nor LLVM_TARGETS_TO_BUILD? If so, I guess you are triggering the x86+ARM capabilities from that CMAKE_OSX_ARCHITECTURES setting.
If this works I’m going to file some bugs about the documentation.
LLVM_RUNTIME_TARGETS is not even in the cache, LLVM_TARGETS_TO_BUILD is x86;ARM;AArch64;NVPTX, but I don’t set that explicitly either.
I don’t claim that this is the right way to to build it, just that it works. Compared to all other targets, the Darwin configuration we need to do is minuscule (probably because the defaults can be reasonably good due to Apple being a singular platform with little variation in hardware and software capabilities).
Okay, I finally got a cmake command to work, and in about 60 minutes I’ll know if the build worked.
It’s an error not a warning for me. Maybe your Python scripts working some other magic?
So I used -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;compiler-rt" and moved those three out of -DLLVM_ENABLE_PROJECTS.
% cmake -S llvm -B build -G Ninja
-DCMAKE_OSX_ARCHITECTURES="x86_64;arm64"
-DCMAKE_LINKER="/usr/bin/ld" -DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=ld"
-DCMAKE_SHARED_LINKER_FLAGS="-fuse-ld=ld"
-DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-apple-darwin
-DLLVM_ENABLE_PROJECTS="clang-tools-extra;clang;lld;llvm;compiler-rt;libcxx;libcxxabi"
-DLLVM_DISTRIBUTION_COMPONENTS="clang-apply-replacements;clang-format;clang-query;clang-resource-headers;clang-tidy;clang;clangd;clang-extdef-mapping;cmake-exports;dsymutil;lld;llvm-addr2line;llvm-ar;llvm-as;llvm-cov;llvm-cvtres;llvm-cxxmap;llvm-dlltool;llvm-dwp;llvm-dwarfdump;llvm-install-name-tool;llvm-lib;llvm-lipo;llvm-nm;llvm-objcopy;llvm-objdump;llvm-pdbutil;llvm-profdata;llvm-ranlib;llvm-rc;llvm-readelf;llvm-strings;llvm-strip;llvm-symbolizer;llvm-windres;LTO;builtins;compiler-rt;cxx-headers;compiler-rt"
-DCMAKE_STRIP=strip -DLIBCXX_INSTALL_LIBRARY=OFF -DLIBCXX_INSTALL_HEADERS=ON
-DLIBCXX_USE_COMPILER_RT=ON -DLLVM_LTO_VERSION_OFFSET=3000
-DCOMPILER_RT_BUILD_XRAY=OFF -DCOMPILER_RT_BUILD_GWP_ASAN=OFF
-DCMAKE_BUILD_TYPE=Release
[...]
CMake Error at CMakeLists.txt:139 (MESSAGE):
libcxx isn't a known project:
bolt;clang;clang-tools-extra;compiler-rt;cross-project-tests;libc;libclc;lld;lldb;mlir;openmp;polly;pstl;flang.
Did you mean to enable it as a runtime in LLVM_ENABLE_RUNTIMES?
-- Configuring incomplete, errors occurred!
rob@RobertsMBP llvm-project %
I appreciate the help. I feel like I’m off the beaten path here. If you don’t mind sharing, what’s your motive for building clang from source like this? In my case I wanted to try the latest features in C++, and didn’t want to wait for Apple to release them with Xcode.
My impression is that most paths in this area are “not very beaten” at all, so don’t feel like you are lost - it’s just the wilderness Most folks don’t build compilers, since it’s much easier to use a prebuilt toolchain. This is especially true in the case of Apple targets (double especially because I recently learned that some things in LLVM can’t even be compiled against the public SDK).
If you don’t mind sharing, what’s your motive for building clang from source like this?
In my case, I’m maintaining this toolchain because our product (Plex Media Server) needs to target a whopping 24 configurations (OS x Arch combinations, and a few others), many of which are not readily available as targets in prebuilt toolchains. Building our toolchain allows minimizing the maintenance cost between different compilers & STLs, as well using our musl fork that we can use to produce fully portable dynamically linked executables on Linux. We also run PGO using our own codebase. Access to latest features is a nice plus, although we don’t need bleeding edge. We do still use MSVC on Windows, but I hope moving to clang soon there (but maybe not libc++, we’ll see). (This toolchain builder was originally created by @tobiashieta BTW, so that’s why he had a hunch that I might have an answer )
So it completed a build without an error, but it looks like it failed to produce libc++ as desired. It produced a bunch of fat binaries for executables (not what I need), but libc++ is x86_64 only, and strangely libc++.a is completely missing. That’s the first time that happened, so perhaps it’s something about your cmake command that I copied without completely understanding it. (Eg: -DLIBCXX_INSTALL_LIBRARY=OFF, or that long list for -DLLVM_DISTRIBUTION_COMPONENTS)
If you want a static libc++, you will probably need to pass -DLIBCXX_ENABLE_STATIC=ON as well (but I’m not certain that it is in a usable state on iOS for example).
As for the universal binaries, it might be difficult to convince the build not to do that. It is very much hardwired to do so (and you will have a better time if you allow it to). Finally, you might want to build the install-distribution-stripped or install-distribution targets.
There are like 800~ish options and cache variables in the LLVM CMake that you can pass to CMake in order to customize your build. Naturally, only a small subset of the possible configurations are actually built by people in world (let alone the LLVM project itself), so anything that differs from the default might be a painful (but not necessarily impossible) endeavor. My impression is that the defaults are especially important on Darwin where Apple dictates the way.
Most folks don’t build compilers, since it’s much easier to use a prebuilt toolchain. This is especially true in the case of Apple targets (double especially because I recently learned that some things in LLVM can’t even be compiled against the public SDK).
)