lld package provides an unwrapped lld. It doesn't always work on NixOS
(eg, it doesn't set rpath), and so dosen't always work.
What one should be using instead is the `lld` from
`llvmPackages.bintools` package. This super counterintutive.
One incremental step we can take here is to clarify that the `lld`
package is unrwapped -- right now, it looks like 100% legit thing one
should be using!
Reduces closure size by ~240MiB (down to ~100MiB) for
LLVM 13, the others are similar.
Having those archives in the lib output makes no sense
as they are no runtime dependencies. Removing them
alltogether is also not an option because the dynamic
libraries offer only the C API while many users of
libllvm require the C++ API. Those users must have an
dependency on libllvm.dev anyway and will find those
files for linking.
substituteStream(): WARNING: pattern '# define _LIBCPP_USE_AVAILABILITY_APPLE' doesn't match anything in file 'include/__config'
The new mechanism for those is a cmake option
LIBCXX_ENABLE_VENDOR_AVAILABILITY_ANNOTATIONS that is off by default:
https://reviews.llvm.org/D90843
libcxxClang still depends on cc wrapper's gccForLibs for libgcc which is
not available when useLLVM is set. In such cases we need to switch to
clangUseLLVM and (try) to use compiler-rt instead.
Resolves#153759: pkgsLLVM.llvmPackages.stdenv now correctly
clangUseLLVM as cc, allowing compilation to work as expected.
llvmPackages_*.clang should check the default compiler for the package
set it is targeting (targetPackages.stdenv.cc) instead of the compiler
that has been used to build it (stdenv.cc) in order to get some sense of
whether to use libc++ or libstdc++.
Since we are now inspecting targetPackages in the llvmPackages.clang
attribute, we need to avoid using it in the cross stdenv — which just
forces us to explicitly request libcxxClang for darwin instead of
relying on the clang attribute to pick it for us.
We also need to do something similar for targetPackages.stdenv.cc: Here
the llvmPackages.clang logic would work as we want (inspect
targetPackages.stdenv.cc and if it doesn't exist, make the choice based
on stdenv.cc), but it gets locked in a cycle with the previous package.
We can easily break this, however: We know that the previous set had
clang and the next one doesn't exist, so we'd choose libcxxClang any day
of the week.
LLVM 12 added the memory profiling runtime and LLVM 13 the ORC
runtime. Both need a libc in order to build (or at least headers not
present in clang's resource root), so we'll disable them for any sort of
baremetal-ish build. memprof likely doesn't work in a baremetal
situation at all, orc is unknown. Whether both would compile with musl
is to be checked.
The main thing we need to pass LLVM_ENABLE_PIC=OFF to prevent LLVM from
building shared objects because our cc-wrapper is incapable of producing
shared objects. Building LLVM statically also influences other LLVM
projects like clang and lld -- which can be built linked fully
statically with this change.
To make the value of doCheck in the argument attribute set accurate we
also need to include the condition for cross compilation which normally
is added by stdenv.mkDerivation.
LLVM's build system creates NATIVE/bin/llvm-config by reexecuting cmake
with entirely new flags. Problematically, the `CMAKE_INSTALL_*` flags
are not inherited, causing llvm-config-native to return wrong
installation paths, e. g. CMAKE_INSTALL_LIBDIR would default to `lib64`
on x86_64-linux. Previously this was masked by outputs.patch which
replaced ActiveLibDir with a string passed in from Nix, however
`--cmakedir` for example would turn out to be wrong always, breaking
cross-compilation of e. g. lld.
Additionally LLVM_ENABLE_RTTI needs to be repassed, as it is used to
determine if RTTI is available. Passing LLVM_LINK_LLVM_DYLIB is crucial
if we are building LLVM non-statically: It influences the --shared-mode
flag (which should indicate that -lLLVM is enough to link all
components) and makes --link-shared work in the first place,
i. e. llvm-config-native believes the built shared libs don't exist
unless we repass this flag.
Passing LLVM_LINK_LLVM_DYLIB=ON, however, makes the native build produce
a full libLLVM.so which is something we don't want, so we introduce a
patch which forces llvm-config to link statically against the LLVM
components it needs.
Starting with LLVM 8, clang does no longer use llvm-config to detect the
LLVM installation: https://github.com/llvm/llvm-project/commit/e4faa5c7986b7
Consequently, there is no point passing LLVM_CONFIG_PATH (in fact the
variable is unused currently).
Since both static and shared libs are installed to the same `lib`
output, we override the ActiveLibDir unconditionally.
Fixes `llvm-config-native --link-static --libs`
LLVM 11 libcxxabi has some flags to support usage in the Darwin stdenv,
in particular, `standalone` and `withLibunwind`.
Darwin stdenv needs the `standalone` flag because its `hostPlatform` set
doesn't have `useLLVM` set to true. And it needs `withLibunwind` to
explicitly disable including `libunwind` as a build input.
We also prefix `install_name_tool` in case we're cross-compiling.
This is already done for previous versions of clang which use
a release tarball, but must be done differently for the more
recent versions which use fetchFromGitHub.
Fixes clang-tools clangd wrapper
Commit 199b7c50 "compiler-rt: remove <cyclades.h> from libsanitizer"
broke conditional conditional musl patches.
The change has a few effects:
- pkgsStatic.llvmPackages_{5,6,7}.compiler-rt: fix build on musl after cyclades backport
- pkgsStatic.llvmPackages_{{5..13},git}.compiler-rt: drop incomplete musl patches as
sanitizers are disabled anyway and require more upstream porting.
the fix to extendDerivation in #140051 unwittingly worsened eval performance by
quite a bit. set elements alone needed over 1GB extra after the change, which
seems disproportionate to how small it was. if we flip the logic used to
determine which outputs to install around and keep a "this one exactly" flag in
the specific outputs instead of a "all of them" in the root we can avoid most
of that cost.
To avoid unnecessary builds but this needs to be fixed ASAP. Chromium
already depends on it and a lot of additional packages, including Mesa,
will depend on it after the stable release.
Shea Levy