Commit Graph

156 Commits

Author SHA1 Message Date
Rick van Schijndel
0b45cae8a3
treewide: pkgs/development/compilers: mark broken for darwin 2022-05-30 13:41:09 +02:00
Lassulus
a1780e4b7d
Merge pull request #162607 from waldheinz/libllvm-drop-static
llvmPackages/libllvm: do not include static archives when shared is r…
2022-04-08 19:39:18 +01:00
Aleksey Kladov
6d111cbf61 Clarify that lld package provides unwrapped lld
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!
2022-03-27 18:14:55 -04:00
Matthias Treydte
1748887ff2 llvmPackages/libllvm: move static archives to dev output
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.
2022-03-04 13:05:53 +01:00
John Ericson
baf290023c
Merge pull request #153790 from sternenseemann/cross-bootstrap-logic
Cross bootstrapping logic fixes benefitting llvmPackages
2022-01-08 12:39:30 -08:00
sternenseemann
e238f456b8 llvmPackages_*.clang: pick clangUseLLVM if targetPlatform.useLLVM
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.
2022-01-07 14:52:13 +01:00
sternenseemann
766f5ffb76 llvmPackages_*: respect cc for target when choosing C++ flavour
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.
2022-01-07 14:42:41 +01:00
sternenseemann
e5ccc412d2 llvmPackages_*.libllvm: only build tests if doCheck
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.
2022-01-04 18:40:32 +01:00
sternenseemann
c70dca8249 llvmPackages_*.libllvm: make llvm-config and llvm-config equivalent
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.
2022-01-04 11:09:43 +01:00
sternenseemann
d807aaa30c llvmPackages*.libllvm: drop outputs.patch for llvm-config.patch
Due to gnu-install-dirs.patch llvm-config will return correct results
for --link-shared as well as --link-static even without this patch.
2022-01-04 11:09:43 +01:00
7c6f434c
84fb429d21
Merge pull request #150018 from trofi/fix-llvm-for-gcc-12
llvm_{5..12}: fix tests against upcoming gcc-12
2021-12-31 21:45:53 +00:00
7c6f434c
58a27ea378
Merge pull request #148367 from r-burns/llvm-config-static
llvmPackages_*.llvm: fix llvm-config-native with static libs
2021-12-24 10:25:03 +00:00
Sergei Trofimovich
1ead4951db llvmPackages_5.compiler-rt: fix build against gcc-12
[ 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 |
2021-12-10 19:56:55 +00:00
Sergei Trofimovich
35223810a1 llvm_{5..12}: fix tests against upcoming gcc-12
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.
2021-12-10 09:08:04 +00:00
Ryan Burns
544707d6a4 llvmPackages_*.llvm: fix llvm-config-native with static libs
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`
2021-12-02 19:21:21 -08:00
Sergei Trofimovich
e9dfe892ef llvm_{5..11}: pull upstream build fix for for gcc-12
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.
2021-11-21 09:50:01 +00:00
Vladimír Čunát
68c40000a7
Merge #141397: llvmPackages_{5,6,7}.compiler-rt: fix patches 2021-10-21 20:26:37 +02:00
Sergei Trofimovich
a410420844 pkgsStatic.llvmPackages_{{5..13},git}.compiler-rt: drop unused musl patches
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.
2021-10-21 18:42:31 +01:00
pennae
dc895fb281 lib: make extendDerivation lighter on eval
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.
2021-10-15 16:39:10 +02:00
Sergei Trofimovich
02310b34b5 llvm_5: disable print_context.c (fails on gcc-11 / dwarf-5)
gcc-11 defaults to -gdwarf-5 and makes llvm symbolizer test fail.
As it's the only failing test let's just skip it for llvm-5.
2021-09-22 21:43:16 +01:00
Sergei Trofimovich
199b7c505b compiler-rt: remove <cyclades.h> from libsanitizer
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.
2021-09-20 19:37:19 +01:00
Yureka
b0f27ee74d llvmPackages_*: expose release_version 2021-08-20 23:07:43 +02:00
Sergey Makarov
a70bc70c14
compiler-rt: Rename llvm argument to libllvm for consistency.
All other `llvm` derivations use name `libllvm` for this argument.
2021-08-09 18:30:59 +03:00
Matthew Bauer
91578ff6f8 compiler-rt{5,6,7,8,9,10}: mark broken on aarch64-darwin
These don’t have support for this platform, so just mark it as broken
for now.
2021-06-23 22:54:24 -05:00
sternenseemann
3530837417 llvmPackages*.clang: fix linker invocation with LLVMgold plugin
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.
2021-05-18 16:15:03 +02:00
John Ericson
e830db4320 llvmPackages: Fix more inconsistencies
The main thing was using `llvm_meta` in all versions.

Secondarily:

 - libunwindx7: Forgot to split outputs

 - libcxx{,abi} 12: Forgot to apply output-splitting patches.

 - simplify `useLLVM` stdenv-switching logic.

 - openmp always gets its own directory
2021-05-12 00:16:11 +00:00
John Ericson
e0d3c9d031 llvmPackages*.libcxx*: Always use the attribute name for pname
This decision was made in a902d99422 but
just for LLVM 12. Now we apply it consitently.
2021-05-12 00:14:56 +00:00
John Ericson
cf02b24813 Merge remote-tracking branch 'upstream/staging-next' into staging 2021-05-11 22:30:46 +00:00
Vladimír Čunát
6b3b7940ff
llvm*Packages: fix output selection (lib.get*) 2021-05-11 10:45:11 +02:00
John Ericson
8629936f82 compiler-rt: Revert passing COMPILER_RT_OS_DIR and not symlinking libs
In 7869d16545 I got rid of the symlinking
by forcing `COMPILER_RT_OS_DIR` to always be the empty string. I thought
this was good because it just make compiler-rt be installed in a normal
way.

However, various LLVM tools expect the `COMPILER_RT_OS_DIR` to be set
normally, and fail to find things when they aren't in the expected lib
subdir.

Maybe it would be best to patch that too in the long term, but for now
we just undo this change.
2021-05-09 22:52:09 +00:00
Andrew Childs
7869d16545 llvmPackages: Multuple outputs for everythting
Also begin to start work on cross compilation, though that will have to
be finished later.

The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.

Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.

----

Other misc notes, highly incomplete

- lvm-config-native and llvm-config are put in `dev` because they are
  tools just for build time.

- Clang no longer has an lld dep. That was introduced in
  db29857eb3, but if clang needs help
  finding lld when it is used we should just pass it flags / put in the
  resource dir. Providing it at build time increases critical path
  length for no good reason.

----

A note on `nativeCC`:

`stdenv` takes tools from the previous stage, so:

1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`

while:

1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
2021-04-30 05:41:00 +00:00
sternenseemann
081b9423d4 llvmPackages*: fix paths to libcxx-0001-musl-hacks.patch
This patches are included from libcxx and libcxxabi when
stdenv.hostPlatform.isMusl. After #117433 the patchs to that patch
wasn't adjusted for the new structure, likely because it doesn't come up
during normal eval. This fixes (among other attribute paths):

* pkgsMusl.llvmPackages_12.libcxxabi
* pkgsMusl.llvmPackages_12.libcxx
* pkgsMusl.llvmPackages_11.libcxxabi
* pkgsMusl.llvmPackages_11.libcxx
* pkgsMusl.llvmPackages_10.libcxxabi
* pkgsMusl.llvmPackages_10.libcxx
* pkgsMusl.llvmPackages_9.libcxxabi
* pkgsMusl.llvmPackages_9.libcxx
* pkgsMusl.llvmPackages_8.libcxxabi
* pkgsMusl.llvmPackages_8.libcxx
* pkgsMusl.llvmPackages_7.libcxxabi
* pkgsMusl.llvmPackages_7.libcxx
* pkgsMusl.llvmPackages_6.libcxxabi
* pkgsMusl.llvmPackages_6.libcxx
* pkgsMusl.llvmPackages_5.libcxxabi
* pkgsMusl.llvmPackages_5.libcxx

Only evaluation was tested, not compilation though.
2021-04-15 13:24:04 +02:00
John Ericson
19a974945b llvmPackages: Organize files
Always do pkg/default.nix not pkg.nix; use directories to avoid
prefixing patches and other files.
2021-03-24 05:02:50 +00:00
Andrew Childs
8cc0010f0c llvmPackages_*.compiler-rt: use darwinArch 2021-03-19 20:23:23 +00:00
John Ericson
0710308402 clang, cc-wrapper: Move --gcc-toolchain logic into CC wrapper
Take 2, after #94582 had to be reverted.

This reverts commit ac03cfa3c5.
2021-01-24 15:49:32 -05:00
Gabor Greif
5105bf4b2e
llvm_{5,6,8..11}: fix missing lib from stdenv.lib -> lib (#110643)
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
2021-01-24 01:31:45 +01:00
Ben Siraphob
acc5f7b18a pkgs/development/compilers: stdenv.lib -> lib 2021-01-23 08:57:37 +07:00
Ben Siraphob
3ae5e6ce03 treewide: remove enableParallelBuilding = true if using cmake 2021-01-03 18:37:40 +07:00
Vladimír Čunát
ac03cfa3c5
Revert "Merge #94582: clang, cc-wrapper: Move --gcc-toolchain logic..."
This reverts commit 0f25eb3e7d, reversing
changes made to df91ae1ac0.

These toolchain changes are too problematic, so reverting for now; see
https://github.com/NixOS/nixpkgs/pull/107086#issuecomment-749196366
2020-12-21 22:27:54 +01:00
John Ericson
11302dc1cf clang, cc-wrapper: Move --gcc-toolchain logic into CC wrapper 2020-11-29 16:18:01 +00:00
Andrew Childs
ddd17201ab compiler-rt: prevent platform sniffing on Darwin
Exposed by the tbd stubs which contains fat libraries. The previously
used proxy libraries were x86_64 only.
2020-11-09 20:00:39 +09:00
Vladimír Čunát
336bc8283b
Re-Revert "Merge #101508: libraw: 0.20.0 -> 0.20.2"
This reverts commit c778945806.

I believe this is exactly what brings the staging branch into
the right shape after the last merge from master (through staging-next);
otherwise part of staging changes would be lost
(due to being already reachable from master but reverted).
2020-10-26 08:19:17 +01:00
Maxim Krivchikov
172f3a197e lldb_5, lldb_6: add patch for >=python-3.7 2020-09-20 08:31:46 -07:00
John Ericson
b5f7ed6846
Merge pull request #91293 from Ericson2314/cxx-wrapper-debt-part-2
treewide: Get rid of `cc.gcc`
2020-08-02 20:42:20 -04:00
John Ericson
92f96f47b0 treewide: Get rid of cc.gcc
Instead, we have a new `gccForLibs`, which has the appropriate
definition for e.g. avoiding `x86_32` linking problems.
2020-08-02 17:12:05 +00:00
Matthew Bauer
b22fc7f03b
Merge pull request #91682 from DieGoldeneEnte/clang_rtti
clang_{5..10}: add RTTI
2020-07-28 14:47:54 -05:00
Maximilian Bosch
2c60e7c2d0
llvm*: compiler-rt: fix build w/glibc-2.31
https://hydra.nixos.org/build/122885657 and more.

Original upstream fix (available in llvm_10):

   947f969244
2020-06-29 14:41:43 +02:00
Holger Wünsche
0f0b14258b
clang_{5..10}: add RTTI
This fixes problems with missing symbols when using clang as library and
is most likely a result of llvm being build with RTTI enabled.
2020-06-27 20:37:11 +02:00
John Ericson
f3f7612a40 C++ Compilers: Systematize handling of standard libraries 2020-06-22 04:24:44 +00:00
John Ericson
1ac5398589 *-wrapper; Switch from infixSalt to suffixSalt
I hate the thing too even though I made it, and rather just get rid of
it. But we can't do that yet. In the meantime, this brings us more
inline with autoconf and will make it slightly easier for me to write a
pkg-config wrapper, which we need.
2020-05-12 00:44:44 -04:00