how to build darwin runtimes as libcxx / libcxxabi as universal?

Hello,

First of all apologies for the niche question. As part of our older systems support on MacPorts, I am attempting a universal runtimes build of libcxx and libcxxabi using gcc8 as the initial build compiler. Currently I am using the llvm-7.1.0 tree for this.

The clang bootstrap compiler is to be built as native arch, then I would like to use that clang to make the universal runtimes.

We use the following initially to make sure that gcc8 builds the bootstrap compiler in the native arch:

CMAKE_OSX_ARCHITECTURES=“x86_64”

This actually works just fine to generate libcxx/libcxxabi in the native arch, but try as I may, I cannot find a way to make libcxx and libcxxabi build as universal binaries using the bootstrap compiler.

I tried adding runtime targets:

-DLLVM_ENABLE_RUNTIME_TARGETS="i386-apple-darwin10;x86_64-apple-darwin10”

or just forcing the CXXFLAGS and CCFLAGS to include “-arch i386 -arch x86_64” but no luck.

I was wondering if first of all building the runtimes as universal is supported (I know it is in compiler-rt) and if so, is there an approach or runtimes configuration option I am meant to set for this?

Best,

Ken

Our current configure line looks like this, with a bunch of MacPorts’ standard cmake defaults in there:

cd “/opt/local/var/macports/build/_opt_myports_lang_libcxx/libcxx/work/build” &&

CXX=g+±8.0 CC=gcc-8.0
cmake -G “CodeBlocks - Unix Makefiles”
-DCMAKE_BUILD_TYPE=Release
-DCMAKE_INSTALL_PREFIX=”/opt/local”
-DCMAKE_INSTALL_NAME_DIR=“/opt/local/lib”
-DCMAKE_SYSTEM_PREFIX_PATH=”/opt/local;/usr”
-DCMAKE_C_COMPILER_LAUNCHER=/opt/local/bin/ccache
-DCMAKE_CXX_COMPILER_LAUNCHER=/opt/local/bin/ccache
-DCMAKE_C_COMPILER=“$CC”
-DCMAKE_CXX_COMPILER=”$CXX”
-DCMAKE_OBJC_COMPILER=“$CC”
-DCMAKE_OBJCXX_COMPILER=”$CXX”
-DCMAKE_POLICY_DEFAULT_CMP0025=NEW
-DCMAKE_POLICY_DEFAULT_CMP0060=NEW
-DCMAKE_VERBOSE_MAKEFILE=ON
-DCMAKE_COLOR_MAKEFILE=ON
-DCMAKE_FIND_FRAMEWORK=LAST
-DCMAKE_EXPORT_COMPILE_COMMANDS=ON
-DCMAKE_MAKE_PROGRAM=/usr/bin/make
-DCMAKE_MODULE_PATH=“/opt/local/share/cmake/Modules”
-DCMAKE_PREFIX_PATH=”/opt/local/share/cmake/Modules”
-DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON
-DCMAKE_INSTALL_RPATH=“/opt/local/lib”
-DPYTHON_EXECUTABLE=/opt/local/libexec/libcxx-bootstrap/bin/python2.7
-DLIBXML2_LIBRARIES=IGNORE

-DCMAKE_OSX_ARCHITECTURES="x86_64”
-DCMAKE_OSX_DEPLOYMENT_TARGET="10.6”
-DCMAKE_OSX_SYSROOT=“/“
-DLLVM_TARGETS_TO_BUILD="X86”

-DLLVM_ENABLE_PROJECTS="clang”
-DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi”
/opt/local/var/macports/build/_opt_myports_lang_libcxx/libcxx/work/libcxx-7.1.0/llvm

&& make install-cxx install-cxxabi

This is currently not supported. We only support building universal binaries in the compiler-rt build.

I’d like to introduce support for building universal binaries for other runtimes as well, but I don’t know yet what’s the right strategy.

The way compiler-rt approaches the problem is by creating a separate target for each supported system and architecture and then combining the output artifacts. This is all done within a single CMake build.

In the runtimes build, we use a separate CMake build for each target. You could build all other runtimes for different targets using that approach and then combine the output together. That’s the approach that Apple uses in https://github.com/llvm/llvm-project/blob/main/libcxx/utils/ci/apple-install-libcxx.sh

We could implement universal binary support in the runtimes, combining output artifacts with llvm-lipo. What I don’t know is how to fit the compiler-rt build into that model. I can see two ways forward:

  1. We implement the same approach that compiler-rt uses in other runtimes, that is we implement support for building libc++, libc++abi and libunwind for multiple targets within a single CMake build. In the runtimes build, we then use a single target for the “universal build”.
  2. We implement universal binary support in the runtimes build and we stop using the existing support in the compiler-rt build when targeting Apple platforms.

I’m leaning towards #2 which seems like a better long term strategy but I’d like to hear from Chris who has already looked into this problem in the past. Have I missed anything? Is there another approach that you’d prefer?

Thank you, that script is indeed a helpful template. I will use that approach for now.

Best,

Ken