[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)

[Michael Kruse via llvm-branch-commits]

Meinersbur wrote:

> Thanks for the fixes and explanations!
> 
> > IMHO whether building shared or static libs should not depend on a configuration parameter.
> 
> This seems strange to me, as that's _exactly_ what `-DBUILD_SHARED_LIBS=` is for, generally. 

`BUILD_SHARED_LIBS` serves a different use case. Most applications/libaries are distributed with just one of them. E.g. Debian-bases OSs have a policy to always use the shared library in distributed applictaions. If you compile a library from source for your own application you know which version you use. CMake was designed around this assumption and has no mode to build both of them. It also has implementation reasons, and it is mostly the usual suspect Windows where both static and dynamic library use a file `libname.lib`. In case of a shared library, that archive only contains shims that lookup and call functions from a DLL. Even under UNIX, using global variables with an arbitary mix of shared and static libraries is asking for problems.

The use case of a toolchain/runtime libraries is different. Sometimes it is going to be used as static library and other times as shared, or even both on the same system. We do not know it advance. So we need both. E.g. Debian provides `libc.a` and `libc.so`, `libquadmath.a` and `libquadmath.so`, `libstdc++.a` and `libstdc++.so`, despite the shared library policy.

What other LLVM runtimes do (AFAIK):
 * openmp: `LIBOMP_ENABLE_SHARED` contols shared or static (i.e. `BUILD_SHARED_LIBS` is ignored). Default ON. Except ompd which is always shared and libarcher which is always both.              
 * offload: always shared (except plugins which are always static and linked into the shared library)
 * compiler-rt: clang_rt.builtins is always static. Others (a.g. sanitizers) are always both.
 * libc: Differentiates between entrypoint libraries (always static) and redirector libraries (always shared)
 * libc++: Builds both by default. Controlled by LIBCXX_ENABLE_SHARED/LIBCXX_ENABLE_STATIC.
 * libc++abi: Builds both by default. Controlled by LIBCXXABI_ENABLE_SHARED/LIBCXXABI_ENABLE_STATIC.
 * libunwind: Builds both by default. Controlled by LIBUNWIND_ENABLE_SHARED/LIBUNWIND_ENABLE_STATIC
 * pstl: header-only library

Flang-RT following `BUILD_SHARED_LIBS` would be the odd one out. 

> You could argue that the runtime should provide both static and shared builds (which is fair), but it should still be possible to choose if I want static, shared or both (this choice has very concrete implications for redistribution, so it needs to be made consciously, and the build system doing it behind our backs is not nice).

Usually, users chose the library to use with linker flags (`-static`). If you have a redistribution for which you don't want to support the shared/static version, then... don't redistribute it? But generally, users prefer to work on the same dev environment everywhere. Am I missing something?

There are probably other reasons why libc++/libc++abi/libunwind offer the possibility to not always build both, I would follow their example. IIAC the feature was added only after OBJECT libraries became available in CMake (see [libunwind](https://reviews.llvm.org/D23233)), and `LIBOMP_ENABLE_STATIC` was just not yet introduced since then.

https://github.com/llvm/llvm-project/pull/110217