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.
This fixes a CI warning [0]:
Run cat "$HOME/changed_files" | xargs -r editorconfig-checker -disable-indent-size
pkgs/development/compilers/llvm/14/lld/default.nix:
28: Wrong indent style found (tabs instead of spaces)
29: Wrong indent style found (tabs instead of spaces)
30: Wrong indent style found (tabs instead of spaces)
[0]: https://github.com/NixOS/nixpkgs/runs/5351700772
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`
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.
llvm/gnu-install-dirs.patch: I've dropped most of the changes to
docs/CMake.rst as they aren't relevant for Nixpkgs and the restructuring
of that file makes it a bit annoying to resolve them via Git.
This also fixes the libunwind build (even with GCC 11 it fails with):
/build/source/libunwind/src/libunwind.cpp:19:5: warning: "__has_feature" is not defined, evaluates to 0 [-Wundef]
19 | #if __has_feature(address_sanitizer)
| ^~~~~~~~~~~~~
/build/source/libunwind/src/libunwind.cpp:19:18: error: missing binary operator before token "("
19 | #if __has_feature(address_sanitizer)
| ^
And the openmp build which failed with this error:
/nix/store/a4yw1svqqk4d8lhwinn9xp847zz9gfma-bash-4.4-p23/bin/bash: CLANG_TOOL-NOTFOUND: command not found
/nix/store/a4yw1svqqk4d8lhwinn9xp847zz9gfma-bash-4.4-p23/bin/bash: CLANG_TOOL-NOTFOUND: command not found
make[2]: *** [libomptarget/deviceRTLs/amdgcn/CMakeFiles/libomptarget-amdgcn-gfx906.dir/build.make:307: libomptarget/deviceRTLs/amdgcn/task.gfx906.bc] Error 127
make[2]: *** [libomptarget/deviceRTLs/amdgcn/CMakeFiles/libomptarget-amdgcn-gfx900.dir/build.make:307: libomptarget/deviceRTLs/amdgcn/task.gfx900.bc] Error 127
The version will initially remain the same so that no additional changes
to the packaging are required (i.e. this commit only includes the
required changes to build from the mono repository instead of individual
tarballs).
The purpose of this package is to continuously improve the LLVM
packaging in Nixpkgs without causing a lot of rebuilds and provide more
recent LLVM builds for users. For more details see:
https://github.com/NixOS/nixpkgs/issues/114828
Shea Levy