For some reason, we have been inserting the ABI specification into the
middle of the target triple, when building LLVM, like so:
armv6-gnueabi-freebsd12.0
This is the wrong way around. LLVM even auto-canonicalizes it to:
armv6--freebsd12.0-gnueabi
Let's do this the right way in llvm.build.mk instead. While here,
define a proper VENDOR macro which can be overridden easily.
Reviewed by: emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D10846
-mlong-calls was set only in STATIC_CXXFLAGS, but there are some .c
source files in LLVM which also need -mlong-calls.
Unfortunately this is not sufficient to fix linking lldb on ARM,
because LLVM-generated calls to __aeabi_read_tp do not honour the
-mlong-calls flag. See LLVM PR31769 for details.
Reviewed by: dim
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D9348
* Bootstrap llvm-tblgen and clang-tblgen with a minimal llvm static
library, that has no other dependencies.
* Roll up all separate llvm libraries into one big static libllvm.
* Similar for all separate clang and lldb static libraries.
* For all these libraries, generate their .inc files only once.
* Link all llvm tools (including extra) against the big libllvm.
* Link clang and clang-format against the big libllvm and libclang.
* Link lldb against the big libllvm, libclang and liblldb.
N.B.: This is work in progress, some details may still be missing.
It also heavily depends on bsd.*.mk's support for SRCS and DPSRCS with
relative pathnames, which apparently does not always work as expected.
For building llvm, clang and lldb though, it seems to work just fine.
The main idea behind this restructuring is maintainability and build
peformance. The previous large number of very small libraries, each
with their own generated files and dependencies was slow to traverse
and hard to understand.
Possible future improvements:
* Only build certain targets, e.g. for most regular users having just
one target will be fine. This will shave off some build time.
* Building the big llvm, clang and lldb libraries as shared (private)
libraries.
* Adding other components from the LLVM project, such as lld.