This is the supported way rocm is tested.
It makes packaging in nix a *lot* easier (see the code size).
An important change is the dontLink detection in the clang/clang++
wrapper script: When compiling with --cuda-device-only,
the linker must not be set, otherwise e.g. the blender kernels fail to
compile.
It is possible to both be bare metal and have a libc (newlib).
This libc doesn't provide very much --- not enough for CMake to think
the C toolchain works. We therefore adjust our logic so we hit the "bare
metal" case with or without libc.
The "use LLVM" bootstrap is intentionally not affected.
GCC 10 sets -fno-common by default. This broke some packages, so
when moving to GCC 10 we initially disabled this behavior. This
commit reverts that, bringing us closer to the standard and
upstream.
Co-authored-by: Sergei Trofimovich <slyich@gmail.com>
Reverts #162607 / 1748887ff2.
Reason for revert: This change caused llvm-config{,-native} to be unable
to find static archives bundled with LLVM, as has been [reported]. Ever
since #152944 using moveToOutput in LLVM is _evil_ because llvm-config
obtains it knowledge about the installation locations from the CMake
configure step.
Consequently a change like #162607 will need to be implemented by making
LLVM itself install the static archives to the correct location or by
adding yet another patch which updates llvm-config's knowledge of the
location. The latter is not desireable in my opinion, though, since it
is just asking for this sort of trouble: Before #152944 we had an
outputs.patch that did this sort of things which broke spectacularly in
edge cases.
Fixes#148117.
[reported]: https://github.com/NixOS/nixpkgs/issues/148117#issuecomment-1158245576
Fixes#166833.
The build creates a symlink for this assuming it's present,
so be sure it's there when filtering the source for clang.
Alternatively we could use LLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR.
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!
This seems to fix the notorious "CommandLine Error: Option 'xxxxx'
registered more than once!" error in applications that use both Mesa and
ROCm.
Since Mesa is built with llvmPackages_latest and ROCm stuff is built
with llvmPackages_rocm, applications that use both (such as Blender) end
up with two different `libLLVM*.so`s loaded, which breaks things.
This seems like a straightforward way to fix the problem, and since the
ROCm stack seems to be the only thing in Nixpkgs that uses
llvmPackages_rocm this hopefully shouldn't break anything.
While there might be another way to fix this problem that doesn't
require disabling the shared libraries, I haven't been able to find it
yet, and since this issue seems to affect a lot of people I think it
might make sense to merge this fix for now and revisit it later if a
better solution is found.
This also removes a small patch to rocm-comgr since there are no longer
LLVM shared libraries for it to link against.
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).
[ 11%] Building CXX object lib/xray/CMakeFiles/clang_rt.xray-x86_64.dir/xray_buffer_queue.cc.o
In file included from lib/xray/xray_buffer_queue.cc:15:
lib/xray/xray_buffer_queue.h:35:5: error: 'size_t' does not name a type
35 | size_t Size = 0;
| ^~~~~~
lib/xray/xray_buffer_queue.h:23:1: note: 'size_t' is defined in header '<cstddef>';
did you forget to '#include <cstddef>'?
22 | #include <utility>
+++ |+#include <cstddef>
23 |
In https://gcc.gnu.org/PR103598 we found out that gcc-12
changed __PRETTY_FUNCTION__ slightly and broke llvm-12 (and older)
tests that rely on exact type match. llvm-13 already removed the
qualified names from the expected output.
This change changes expected output to avoid llvm:: namespace prefix.
This is enough to get tests pass on x86_64 again.
Tested against this week's gcc-12 and against gcc-10.
