We can use use `stdenv.hostPlatform.isStatic` instead, and move the
logic per package. The least opionated benefit of this is that it makes
it much easier to replace packages with modified ones, as there is no
longer any issue of overlay order.
CC @FRidh @matthewbauer
Build the llvm support libraries (libcxx, libcxxabi) from scratch
without using the existing llvm libraries. This is the same spirit and
similar implementation as the "useLLVM" bootstrap in llvm package
sets. Critically it avoids having libcxxabi provided by the cc-wrapper
when building libcxx, which otherwise results in two libcxxabi
instances.
$ otool -L /nix/store/vd4vvgs9xngqbjzpg3qc41wl6jh42s9i-libc++-7.1.0/lib/libc++.dylib
/nix/store/vd4vvgs9xngqbjzpg3qc41wl6jh42s9i-libc++-7.1.0/lib/libc++.dylib:
/nix/store/vd4vvgs9xngqbjzpg3qc41wl6jh42s9i-libc++-7.1.0/lib/libc++.1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/nix/store/gmpwk5fyp3iasppqrrdpswxvid6kcp8r-libc++abi-7.1.0/lib/libc++abi.dylib (compatibility version 1.0.0, current version 1.0.0)
/nix/store/3hn7azynqgp2pm5gpdg45gpq0ia72skg-libc++abi-7.1.0/lib/libc++abi.dylib (compatibility version 1.0.0, current version 1.0.0)
/nix/store/1nq94scbxs6bk7pimqhvz76q6cfmbv97-Libsystem-osx-10.12.6/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
Additionally move some utilities (clang, binutils, coreutils, gnugrep)
to the stage layers so they can be replaced before the final
stdenv. This should cause most of stage4 to be built from the
toolchain assembled as of stage3 instead of the bootstrap toolchain.
Because I maintain Chromium which always requires the most recent LLVM
release (would be good to get notified on any PRs/issues, especially
since I seem to end up merging most of the PRs anyway).
See #100725.
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).
llvmPackages_11: 11.0.0rc5 -> 11.0.0 and various fixes/improvements:
- llvmPackages_11 now compiles on Darwin
- libcxx now compiles on Linux
- Ported #91293 to 11.0.0
- Try to anticipate #100388
compiler-rt (and as a result clang) can't be build for i686 (as noticed here: #99984).
The patch adds the required variables and should result in the same behavior as in the nixpkgs-llvm10. It essentially forces to use i386 buildins when using i486, i586 or i686, which are not supported.
Fixes#100392
A port of #85925 for LLVM 11 to enable CFI for Chromium.
This is required for features such as `-fsanitize=cfi` that (by default)
load the file `…/resource-root/share/cfi_blacklist.txt`.
This is used by mesa.drivers (still on LLVM 9) as a cache key. I've
ported that change to LLVM 11 to test it and so that it doesn't get lost
in future versions. Credit for the change goes to David McFarland.
See #93946 for details.
Co-Authored-By: David McFarland <corngood@gmail.com>
This merges #94204 with the only difference being that I modified the
history into three commits that should be easier to review and
understand.
Original history: 3524f4cfa94744bf5058bed6f2e3f6490f4c8e1b
Modified history: df267a4cca
This is needed for cross-compiling for LLVM.
After https://github.com/NixOS/nixpkgs/pull/94088, we still need some
of these, so I’ve whitelisted those that are in binutils.
/cc @DavidTruby
These llvm-prefixed utilities are not drop-in replacements for the utilities
with similar names, they are specifically for operating on LLVM IR files.
Symlinking these without the prefix causes incompatibilities with tools that
expect diff, as and others to behave normally.
This disables all manpages packages depending on recommonmark. This can
be undone once recommonmark supports sphinx 3. The other
manpage-packages don't use recommonmark and don't need to be commented
out.
