The phoney gcc that we construct for multilib was missing the
`$out/include/c++` directory which `cc-wrapper` needs to pass as an
`-isystem` to `clang`.
Closes#221891
The phoney gcc that we construct for multilib was missing the
`langCC` attribute, which `cc-wrapper` needs in order to decide
whether or not to add gcc's `libstdc++` headers as an `-isystem` for
`clang`.
Our gcc_multi and glibc_multi expressions merge together a
32-bit-targeted and 64-bit-targeted gcc. However they do not thread
through the passthru.libgcc from these merged gccs.
This commit corrects that.
It also extends passthru.libgcc to allow a *list* rather than just a
single outpath.
Resolves part of #221891 (at least getting it back to the error
message it gave before).
Darwin-specific builtins were present on x86-64-darwin, but not on
aarch64-darwin. This is the same issue as #186575, but while the fixes
were correctly applied to LLVM 15, we were still disabling the build of
builtins on aarch64-darwin. Likely just a confusion.
clang_15 appears to not cross compile in the build!=(host==target)
case due to two problems, which this commit fixes:
- It trips -Wmaybe-uninitialized on recent gcc, but only in the
build!=host case (likely due to #ifdefs)
- Two more buildPlatform tools have been added:
clang-tidy-confusable-chars-gen and clang-pseudo-gen
Co-authored-by: Rahul Butani <rrbutani@users.noreply.github.com>
bumping `llvmPackages_git` to match `llvmPackages_15`; this will let us
continuing bringing `llvmPackages_git` to parity with `llvmPackages_15`
without needing to invest time and effort into getting the current
llvmPackages_git's commit's test suite to pass under all the platforms,
etc.
this will also allow us to begin diffing derivations between
`llvmPackages_15` and `llvmPackages_git` as a way of tracking down
remaining differences between the package sets
Port of bc4dbee115 ("llvmPackages_15:
updates for LLVM 15").
None of the patches required any touch-up; the only change of note is:
- due to changes in the libc++/libc++abi build
(https://reviews.llvm.org/D120719 and https://reviews.llvm.org/D131037)
we have to add an extra build option to the libc++ header only
build that sidesteps bits of the libc++ build config that assume
libc++-abi is present in the build:
4f827318e3/libcxx/src/CMakeLists.txt (L255-L256)
Rather than maintaining a precise set of build options that let us dodge
referencing libc++-abi variables in the libc++ header only build, we set
`LIBCXX_CXX_ABI` to `none`, as suggested by @lovesegfault.
More discussion about this here: https://github.com/NixOS/nixpkgs/pull/194634#discussion_r990267037
Co-authored-by: Bernardo Meurer <bernardo@meurer.org>
Port of c7231c0b6d ("llvmPackages_15.llvm: run the tests on macOS").
The sysctl native check input was taken from
6d0c87602f ("llvmPackages_15.llvm: add in a missing check dep"),
because it looks like it was supposed to be part of c7231c0b6d
instead.
Port of 6d0c87602f ("llvmPackages_15.llvm: add in a missing check
dep").
I did not include the sysctl nativeCheckInputs change from that
commit, as it looks like it was included by mistake and was supposed
to be in c7231c0b6d ("llvmPackages_15.llvm: run the tests on macOS").
I've also included the doCheck default from that commit (without the
change to run on non-Linux), as 6d0c87602f just set it to true.
Port of 404ef6b6c9 ("llvmPackages_15.clang: drop the C++ std version
`-DCMAKE_CXX_FLAG`"). The commit mentioned as removing the need for
the override[1] first appeared in LLVM 10.
[1]: 2724d9e129
Port of 2a58596dd2 ("llvmPackages_15.llvm: enable polly by default").
It should be ported all the back to LLVM 12, but I haven't done that
here because going further back than 14 requires fixing patches, and
I'm focused on my goal of getting the delta between LLVM 15 and LLVM
git under control — it's going to be hard enough to accomplish that.
compiler-rt has accumulated several regressions that prevent it from building
on ARMv6. It is important to note that there are two major versions of ARMv6:
base ARMv6 and ARMv6K. ARMv6K includes several important new instructions,
such as non-word size atomic operations (ldrexd, strexd, etc.) and the yield
instruction. Most ARMv6 CPUs actually implement ARMv6K, including all those used
in Raspberry Pis, but nixpkgs' "raspberryPi" platform targets base ARMv6.
compiler-rt versions 8-14 fail to build on ARMv6 and ARMv6K. compiler-rt 15 (not
yet in nixpkgs) builds on ARMv6K but not ARMv6. This patch fixes versions 9-14
on both ARMv6 variants. The patches don't apply cleanly to version 8, and I
figured it wasn't worth carrying another version of the patches for such an old
version.
A total of five patches are required to get compiler-rt building on ARMv6:
* armv6-mcr-dmb.patch: use `mcr` to provide the equivalent of `dmb` on ARMv6.
Included in LLVM 15.
* armv6-sync-ops-no-thumb.patch: prevent certain atomic operation functions
from using Thumb mode. Included in LLVM 15.
* armv6-no-ldrexd-strexd.patch: don't use ldrexd or strexd, which are not
available in base ARMv6. Submitted upstream by me.
* armv6-scudo-no-yield.patch: use nop instead of yield on ARMv6 in standalone
scudo. Required by versions >=13, since they enable standalone scudo.
Submitted upstream by me.
* armv6-scudo-libatomic.patch: link standlone scudo to libatomic on ARMv6 (and
any other platforms that need it). Not yet submitted because the backport is
a bit different from the upstream version and I need to test it.
This was added in 00839fea22 ("llvmPackages_15.compiler-rt: fixes for Darwin"),
which says:
> this introduces a codesigning related patch that we can drop once
> #195107 goes through
The referenced PR ("sigtool: 0.1.2 → 0.1.3") has now been merged, so
I'm dropping the patch as instructed.
The effect of `.out // { outputSpecified = false; }` in these cases
is to select the default output explicitly, but then make the
selection implicit until `overrideAttrs` is called. Previously
`overrideAttrs` would not preserve output selection, masking the
apparently unnecessary behavior of this workaround.
For `libllvm-polly`, this logic does not apply, as it does not
select the default output.
The `outputSpecified` workaround was introduced in
https://github.com/NixOS/nixpkgs/pull/122554
and was perhaps rushed because of a release deadline, and expected
delays from mass rebuilds.
The change in `overrideAttrs` behavior was added in
5b2f597b11 / https://github.com/NixOS/nixpkgs/pull/211685
and the problem was discovered in https://github.com/NixOS/nixpkgs/pull/218537,
which may contain further information.
Port of 44165d3657 ("llvmPackages_{14, git}.clang: add nostdlibinc flag")
to Clang 15. It was originally thought this wasn't needed[1], but it is,
to fix expressions like the following:
with import ./. {};
llvmPackages_15.libcxxStdenv.mkDerivation {
name = "libcxx-stdenv-c++-test";
dontUnpack = true;
input = ''
#include <cstdlib>
int main() {
std::abort();
return 0;
}
'';
passAsFile = [ "input" ];
installPhase = ''
$CXX -c -o $out -x c++ $inputPath
'';
}
[1]: https://github.com/NixOS/nixpkgs/pull/194634#issue-1398202534
This reverts commit 386aba3115.
As I understand it from reading
<https://llvm.org/docs/DeveloperPolicy.html#copyright-license-and-patents>,
the structure of LLVM licensing is as follows:
- They're in the process of relicensing to Apache-2.0 WITH LLVM-exception,
but they haven't got permission to relicense all the code yet.
This means that some of the code can be used under the new license,
but not all of it, and it's difficult to know which is which. This
license is therefore probably not useful yet, until the relicensing
effort is commit.
- While the relicensing effort is ongoing, code being contributed to
LLVM has to have permission to be used under the old and new
licensing schemes. Since the new licensing scheme can't be used
for all code yet, it only makes sense to use LLVM's code under the
old licensing scheme at the moment.
- The old licensing scheme is that code for the LLVM components we
care about is all available under the NCSA license, and some
components are optionally available under a different license,
usually the MIT license, instead.
So I think we should go back to just listing NCSA, or NCSA/MIT, and
forget about the new license until it actually becomes useful,
i.e. LLVM's relicensing effort is complete.
