On 01.01.2019 14:33, Martin Husemann wrote: > On Tue, Jan 01, 2019 at 05:45:31AM +0100, Kamil Rytarowski wrote: >> LLVM has no API/ABI stability contract and we are down to just keep >> syncing the headers and libraries with LLVM releases. > > Can you explain this in more detail? Sounds like a no-go to me. >
The LLVM projects do not retain compatibility between major releases and we need to live with it. There are 2 releases yearly and we need to sync the libraries and headers installed. These libraries and projects are mostly needed for other LLVM projects (OpenMP, Polly, ..) and few external projects that are tracking LLVM (like Rust). Right now our LLVM version in base is stripped down from features and we need to keep rebuilding the full stack from pkgsrc or for development purposes manually out of the pkgsrc context as pkgsrc isn't enough compatible with it (wrappers are messing with compilation flags).. however there is a problem, that the LLVM projects (especially low-level parts) are closely tight to be built together with the base system. We have hardcoded setup in the Clang driver for the base libc++ setup. In reality OSes are performing analogous task to NetBSD, as they are reimplementing build rules in appropriate languages and integrating cherry-picked LLVM components according to needs. Google maintains gn/bazel builds of LLVM projects. Certain projects shall be divided between non-python and python features. Python is needed for extra features in Clang or LLDB. Python pieces could be fetchable from pkgsrc. Further more we are forced to keep integrating LLVM projects as the CMake scripts are not cross-buildable. I've invested some time into MKSANITIZER from an external toolchain and the conclusions are that we must push it into build.sh tools and src/. Hardcoded customization of Clang/LLVM for NetBSD contributes to the incompatibility. Joerg seems to just want to play with Clang out of the LLVM projects, deteriorating experience with the rest blocking this patch. Other people need more than that. > We provide abi compatibility, so does this mean we just need to bounce > the llvm libs major version on every import or is it worse? > We will need to bump major version with each LLVM upgrade. We need to keep building a selection of LLVM tools to generate or enable building neded LLVM files. One thing that might tricky and considered as worse.. LLVM profile (--coverage option) for some reason has been pushed into NetBSD libc (it's part of compiler-rt) in a legacy version ABI v2. Today LLVM uses ABI v4 and not sure if we can do anything with it without formal libc major bump. > Martin > >
signature.asc
Description: OpenPGP digital signature
