found with fdupes
```
pkgs/development/compilers/llvm/8/clang/purity.patch
pkgs/development/compilers/llvm/5/clang/purity.patch
pkgs/development/compilers/llvm/6/clang/purity.patch
pkgs/development/compilers/llvm/7/clang/purity.patch
```
found with fdupes
```
pkgs/development/compilers/llvm/8/libcxxabi/no-threads.patch
pkgs/development/compilers/llvm/10/libcxxabi/no-threads.patch
pkgs/development/compilers/llvm/9/libcxxabi/no-threads.patch
pkgs/development/compilers/llvm/11/libcxxabi/no-threads.patch
```
What changed:
* Fixed crtbeginS.o and crtendS.o missing
(they may or may not be called crt{begin_end},{,_shared}.
* Fixed implicit function declaration causing build errors for various
builds by supplying -Wno-implicit-function-declaration.
* Fixed __cxxabi_config.h missing, by adding -I${cxxabi}/include/c++/v1
in the wrapper.
* Fixed libcxx failing to build due to missing libunwind symbols by
including libunwind as a buildInput, and setting
-DLIBCXX_ADDITIONAL_LIBRARIES=unwind for stdenv.hostPlatform.useLLVM == true.
* libcxxabi wants to find libunwind at libunwind_shared.so, so symlink
it there in libunwind.
* llvmPackages_16.libcxxabi: Pass -nostdlib via CMAKE_*_LINKER_FLAGS
Without this flag, the link of libcxxabi.so tries to pull in libgcc and
friends, from the clang compiler driver.
* Drop unneeded musl hack patch from libcxx.
* Pass -Wno-error=implicit-function-declaration only to compiler-rt
See LLVM forum discussion:
https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213
In summary, LLVM 16 made implicit function declaration an error. This
happens a lot in configure scripts which can break things.
* llvmPackages_16: !isDarwin: Supply -DLIBCXX_ABI_USE_LLVM_UNWINDER=On
Otherwise it fails with various undefined references to _Unwind_*
functions: (full list: _Unwind_DeleteException _Unwind_GetIP
_Unwind_GetLanguageSpecificData _Unwind_GetRegionStart
_Unwind_RaiseException _Unwind_Resume _Unwind_SetGR _Unwind_SetIP).
* 16.libcxxabi: Only pass -nostdlib for useLLVM and Darwin builds
What was tested:
* x86_64-linux, aarch64-linux, the stdenv builds.
* Additionally I was able to get nix to build, with an overlay to fix
a couple of minor issues in downstream packages (overlay supplied in
PR #246577.
* aarch64-darwin fails spuriously in a single LLVM test
strip-preserve-atime.test checking atime timestamps.
* The same for pkgsLLVM with llvmPackages = llvmPackages_15.
Signed-off-by: Peter Waller <p@pwaller.net>
This fixes two issues on Darwin to allow pkgsStatic to work with LLVM 16
* It fixes an infinite recursion where Darwin was using a regular stdenv
to build compiler-rt instead of one without compiler-rt; and
* It disables sanitizers that won’t build statically and makes sure the
build can find the cross-lipo.
Without the change `llvm` build fails on `gcc-13` fails as:
[ 0%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Signals.cpp.o
In file included from llvm/lib/Support/Signals.cpp:14:
llvm/include/llvm/Support/Signals.h:119:8: error: variable or field 'CleanupOnSignal' declared void
119 | void CleanupOnSignal(uintptr_t Context);
| ^~~~~~~~~~~~~~~
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>
