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
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.
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.
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).
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.
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`
The libcxxabi expression had a `standalone` argument in LLVM 7 which
triggered passing of the `-DLLVM_ENABLE_LIBCXX=ON` flag. In LLVM 11 this
flag and others are toggled by the `useLLVM` attribute of
`stdenv.hostPlatform` but this toggles a flag we don't need on Darwin.
Similar to the refactoring of LLVM 7 libc++abi by Ericson2314 in
3af7e98470, I have reintroduced the standalone argument for use in
bootstrapping the Darwin stdenv.
Without the fix build fails on gcc-12 as:
/build/llvm/lib/Target/NVPTX/NVPTXAsmPrinter.cpp:
In member function 'std::string llvm::NVPTXAsmPrinter::getPTXFundamentalTypeStr(...':
/build/llvm/lib/Target/NVPTX/NVPTXAsmPrinter.cpp:1319:10:
error: use of deleted function 'std::__cxx11::basic_string<...>; std::nullptr_t = std::nullptr_t]'
1319 | return nullptr;
| ^~~~~~~
The patch is present in upstream releases since llvm-12.
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.
linux-headers-5.13 removed <cyclades.h> along with device support.
Backport a single https://reviews.llvm.org/D102059 upstream change to
fix compiler-rt build.
Use local patches as there is a whitespace change compared to upstream.
The test suite leads to nothing but tears, sorrow, and wasted build
time. It probably should be disabled for all of them but doing only
9 (llvmPackages) and 11 (llvmPackages_latest, Rust) for now. Some of
the failures have been fixed in LLVM main:
- https://reviews.llvm.org/D97490
- https://reviews.llvm.org/D91043
When using GNU binutils, clang passes the LLVMgold.so plugin to the
linker for certain operations that require special support in the linker
like doing link time optimization (LTO). When passing the plugin to the
linker's command line, clang assumes that llvm and itself are installed
in the same prefix and thus `/path/to/clang/bin/../lib/LLVMgold.so` is
the plugin.
Since we install clang and llvm to separate store paths, this assumption
does not hold. When clang-unwrapped only had a single output, we worked
around this issue by symlinking `$out/lib/LLVMgold.so` to
`${llvm}/lib/LLVMgold.so`. However since we split all llvm packages into
multiple outputs clang's `$out` no longer has a lib directory and clang
can't discover clangs lib output on its own. As a result LTO was broken.
Instead of introducing yet another hack and having a symlink to
LLVMgold.so in `$out/lib` (despite having `$lib/lib` as well), we patch
clang to use a hard coded path to `${libllvm.lib}/lib` for discovering
`LLVMgold.so`.
Resolves#123361.
7869d16545 changed how resource files are
installed. Likely by accident, now some of the resource files are
installed to $dev/include instead of $out/share. This causes the cc
wrapper's resource-root to miss those files from compiler-rt as they are
in a different place than expected.
This commit fixes all instances of this incorrect installation for
llvmPackages_10, 11 and 12 which are the only llvm package sets which
link ${targetLlvmLibraries.compiler-rt.out}/share to the resource-root.
For the other llvm package set this will likely also need to be fixed,
but it doesn't have to have immediate urgency and doing it in two steps
allows us to (hopefully) fix the chromium build without causing a darwin
stdenv rebuild.
The full fix can be found in #123103 and should probably be included in
the next staging-next rotation.
