for hygiene
Run `deadnix . --edit`
`gccForLibs` is an argument used by multi.nix but it's an argument to
cc-wrapper, not to llvmPackages.
`@args` in `llvm/default.nix` was accidentally added in 4badff49fd
There are no uses of `@` therefore these changes are safe.
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>
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>
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.
LLVM-exception only makes sense when used with the Apache 2.0 license,
so let's combine them, so it's not possible to forget one of them like
happened with llvm_15.
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure