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).
