Building llvm and runtime

Question

This is with llvm-project git tag llvmorg-18.1.2, RedHat 7.9 amd64 and I'm building with GCC 13.1 that I built myself (with no problems!).

First question, is it possible to build llvm tools and runtime at the same time?

https://llvm.org/docs/CMake.html

has a "quick start", but so quick that it doesn't even bother to say what the default targets are. It then goes on and on and on with vast numbers of options.

The the separate web site for libc++ gives instructions using ninja

https://libcxx.llvm.org/BuildingLibcxx.html

I don't know much CMake. Is it even possible with CMake to specify two source directories?

Since I can't find a way to build in one go, I'm using 2 scripts to configure.

export CC=`which gcc`
export CXX=`which g++`

cmake \
  -D CMAKE_BUILD_TYPE=Release \
  -D LLVM_ENABLE_RTTI=ON \
  -D LLVM_ENABLE_PROJECTS="clang;clang-tools-extra;lld;lldb;polly;pstl" \
  -D CMAKE_INSTALL_PREFIX=/home/user/tools/clang \
  -D CMAKE_CXX_LINK_FLAGS="-Wl,-rpath,/path/to/gcc-13.1.0/lib64 -L/path/to/gcc-13.1.0/lib64" \
  -B build \
  -S llvm

and for the runtime

export CC=/path/to/clang
export CXX=/path/to/clang++

cmake \
  -D CMAKE_BUILD_TYPE=Release \
  -D LLVM_ENABLE_RTTI=ON \
  -D CMAKE_INSTALL_PREFIX=/home/user/tools/clang \
  -D LLVM_ENABLE_RUNTIMES="compiler-rt;libcxx;libcxxabi;libunwind" \
  -B build_runtimes \
  -S runtimes

Next problem, building the runtimes

[  1%] Linking C shared library ../../lib/libunwind.so
gcc: error: unrecognized command-line option '-nostdlib++'

Wow, how do you manage to mix C++ options with a C compiler? Does this mean that it only builds with clang (assuming clang accepts and ignores C++ options)?

Building tools does a bit better.

[ 86%] Linking CXX shared library ../../../../lib/liblldb.so
/path/to/gcc-13.1.0/lib/gcc/x86_64-pc-linux-gnu/13.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/local/lib/libpanel.so: error adding symbols: file in wrong format

Indeed it is in the wrong format - x86 rather than amd64.

I have no idea why we have a /usr/local/lib symlink to /usr/local. The problem seems to be with the link.txt file. It seems to me that there is a law somewhere that says that scripts to launch link editors must add vast complexity for marginal or zero gain - libtool is just as awful

I edited link.txt by hand (and a second one) and was able to build the tools.

And with the clang and clang++ building the runtimes progressed a bit, but still there are problems. cxx cxxabi and unwind all build OK. With compiler-rt I get

llvm-project/compiler-rt/lib/orc/error.h:134:21: error: no member named 'make_unique' in namespace 'std'
  134 |   return Error(std::make_unique<ErrT>(std::forward<ArgTs>(Args)...));
      |                ~~~~~^
/.../llvm-project/compiler-rt/lib/orc/error.h:134:33: error: 'ErrT' does not refer to a value
  134 |   return Error(std::make_unique<ErrT>(std::forward<ArgTs>(Args)...));
      |                                 ^
/.../llvm-project/compiler-rt/lib/orc/error.h:131:20: note: declared here
  131 | template <typename ErrT, typename... ArgTs> Error make_error(ArgTs &&...Args) {
      |                    ^
/.../llvm-project/compiler-rt/lib/orc/error.h:134:64: error: expected ')'
  134 |   return Error(std::make_unique<ErrT>(std::forward<ArgTs>(Args)...));
      |                                                                ^
/.../llvm-project/compiler-rt/lib/orc/error.h:134:38: note: to match this '('
  134 |   return Error(std::make_unique<ErrT>(std::forward<ArgTs>(Args)...));
      |                                      ^
/.../llvm-project/compiler-rt/lib/orc/error.h:190:44: error: no template named 'remove_reference_t' in namespace 'std'; did you mean 'remove_reference'?
  190 |   using wrap = std::reference_wrapper<std::remove_reference_t<T>>;
      |                                       ~~~~~^~~~~~~~~~~~~~~~~~
      |                                            remove_reference
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/type_traits:1374:12: note: 'remove_reference' declared here
 1374 |     struct remove_reference

GCC may be old and ugly, but it gets the job done.

What am I doing wrong when building compiler-rt?