[RFC] RUNTIMES may be built in-tree and be linked to tools

[chapuni]

Abstract

The most extreme case in RUNTIMES is libcxx. It affects almost all artifacts under compilation. Assume RUNTIMES as libcxx hereafter.
(I know libcxx requires libcxxabi)

tools means LLVM tools, like llvm, clang, etc., including their development libraries.

• Don’t build libcxx in LLVM_ENABLE_RUNTIMES for the host.
• Configure and build libcxx in-tree.
• Configure tools assuming in-tree libcxx
• Build tools with -nostdinc++ and -isystem libcxx
• Link tools to in-tree libcxx

This RFC will make things easier;

• Building and packaging
• Optimizations and instrumentations
  • Make *san easy
  • Make “LTO with libc++” easy
• The daily life

Why avoiding LLVM_ENABLE_RUNTIMES

This builds runtimes with just-built clang. I suppose it as “early next stage”.
Consider the case below.

• The host provides old clang++ and old libc++. clang++ is configured as CLANG_DEFAULT_CXX_STDLIB=libc++.
• Build LLVM_ENABLE_PROJECTS=clang with the host tools and LLVM_ENABLE_RUNTIMES=libcxx.
• Install artifacts to somewhere.

I guess installed artifacts as below.

• clang and other tools depend on host’s old libc++.
• new libc++ may be found in the library path of clang.
  • Old libc++ would disappear if new libc++ replaces old one.

clang and libc++ might be incompatible. It’s odd. Others, dev libs will be incompatible to libc++.

That said, LLVM_ENABLE_RUNTIMES may be available to other non-host targets for multiarch.

Prerequisite(s)

• The host CXX (maybe clang++) should be;
  • Capable of building libc++
  • Available for the host arch (corresponds to autoconf’s --host)

Suggested configurations

• LLVM_ENABLE_PROJECTS may accept libcxx and other runtimes. Such runtimes should be treated specially against other external projects.
• LLVM_ENABLE_RUNTIMES should exclude the host arch if specified. This is not required unless multiarch runtimes would be built.

Planned implementations

I have the PoC tree to do them below.

• Configure libcxx in advance of other libs and tools with the host CXX.
  • Modify (drop) a few flags specified in the upper scope. libcxx should be more generic and C++20-ready.
• Modify flags for tools
  • CXXFLAGS should have -nostdinc++
  • Add in-tree libcxx to include_directories(), especially __config_site.
  • LDFLAGS should be modified to find just-built libcxx in advance of other libc++.
  • Unittests’ RPATH should point to just-built libc++.so if cxx_shared is used.

Future plans

I haven’t proved them for now.

• The host CXX may be freestanding unless using NATIVE tools. The configuration will be satisfied just to test capability of building in-tree libcxx.
  • The configurator of libcxx may be invoked in advance of LLVM’s config-ix. libcxx’s configurator should be responsible to check the host CXX works fine.
  • LLVM’s config-ix should skip some tests, assuming libcxx’s configurator works fine.
• Build non-host other runtimes in-tree (w/o LLVM_BUILD_RUNTIMES)
  • I don’t expect it would be easy. CMake is not designed for cross build.

Self explanation

I was thinking just-built clang would be the best in the past, autoconf age. I have been supposing just-built clang is not suitable to CMake configurations.

Thank you.