Before this change the GHCJS build fails on Linux with:
```
Setup: Missing dependency on a foreign library:
* Missing (or bad) header file: ghc/utils/unlit/fs.h
```
The root cause is that the `./ghc/configure.ac` script is
responsible for copying `./ghc/utils/fs/fs.h` to
`./ghc/utils/unlit/fs.h`, but the script exits early if a C
compiler is not present.
This fixes that by ensuring that the C compiler is present
on all platforms (not just Darwin), so that the build now
works on Linux, too.
Before this change the `ghcjs` build fails with:
```
checking host system type... Invalid configuration `js-ghcjs': machine `js-unknown' not recognized
configure: error: …/bin/bash …/configured-ghcjs-src/lib/boot/pkg/unix/config.sub js-ghcjs failed
```
This fails because the `updateAutotoolsGnuConfigScriptsHook` overrides the
`config.sub` in the `unix` boot package to use the newer upstream
version of `config.sub`, but the newer version is incompatible with the
`js-ghcjs` host string used to configure the `unix` package. The
fix is to undo the override, because the `config.sub` vendored within
`ghc` supports the host string correctly.
This reverts commit d71611fb72, reversing
changes made to cae9272c92.
The update caused an issue on aarch64-linux where it's the default
compiler, many packages got broken (usually through `mariadb`; I think).
File lib/gcc/aarch64-unknown-linux-gnu/9.4.0/include/arm_acle.h
got unbalanced braces (look at `cplusplus` lines), e.g. see in
/nix/store/fvkdvx69sf8h99xgx0m42dzfd5ly5csr-gcc-9.4.0/
I don't know how exactly it happened, as in the source this header is OK
and hasn't even changed between 9.3.0 and 9.4.0. I assume that some
post-processing on headers got broken. Anyway, I don't have much
motivation to dig deeper here, but perhaps someone else will.
[ 11%] Building CXX object lib/xray/CMakeFiles/clang_rt.xray-x86_64.dir/xray_buffer_queue.cc.o
In file included from lib/xray/xray_buffer_queue.cc:15:
lib/xray/xray_buffer_queue.h:35:5: error: 'size_t' does not name a type
35 | size_t Size = 0;
| ^~~~~~
lib/xray/xray_buffer_queue.h:23:1: note: 'size_t' is defined in header '<cstddef>';
did you forget to '#include <cstddef>'?
22 | #include <utility>
+++ |+#include <cstddef>
23 |
In https://gcc.gnu.org/PR103598 we found out that gcc-12
changed __PRETTY_FUNCTION__ slightly and broke llvm-12 (and older)
tests that rely on exact type match. llvm-13 already removed the
qualified names from the expected output.
This change changes expected output to avoid llvm:: namespace prefix.
This is enough to get tests pass on x86_64 again.
Tested against this week's gcc-12 and against gcc-10.
The current build attempts to fetch
https://cdn.azul.com/zulu/bin/zulu17.30.19-ca-jdk17.0.1-macosx_aarch64.tar.gz
on aarch64-darwin, and that URL does not exist.
Changing the Zulu version to 17.30.19 to 17.30.15 fixes the URL, and
the hash requires no changes, indicating that the hash must have
originally been computed for version 17.30.15 anyway.
CONFLICT (rename/add): Rename pkgs/development/python-modules/jsonwatch/default.nix->pkgs/tools/misc/jsonwatch/default.nix in nixpkgs/master. Added pkgs/tools/misc/jsonwatch/default.nix in HEAD
Yasm needs a compiler for the build host available for building the
internal 'genperf' tool.
This fixes cross-compiling yasm. Tested by compiling yasm for
aarch64 on x86_64.
Since both static and shared libs are installed to the same `lib`
output, we override the ActiveLibDir unconditionally.
Fixes `llvm-config-native --link-static --libs`
This is no substantial change, as we already assert that the
build->target and host->target LLVM are the same, but this brings the
terminology in the file in a more consistent order, since we use
build->target for CC/CXX and bintools already.
In fact we should be passing build->target to configure always,
host->target would come into play when updating GHC's settings file
after installing.
On aarch64-darwin we have additional wrappers for install_name_tool and
strip to deal with codesigning requirements (e. g. updating the
signature / checksum after changing a binary). These wrappers don't
exist on x86_64-darwin which is why the unwrapped versions were used
before, causing the kernel to kill (some) executables produced by GHC.
CC, CXX, LD, AR, …, LLC, OPT and CLANG will be invoked by GHC's build
system at build time in the build->target role. However, since we are
passing absolute paths, they will get saved in GHC's settings file and
later invoked at runtime, when they should be host->target. This means
that the build->target and host->target tools need to be the same for
our built GHC to work properly which is what we guard using these new
asserts.
Being able to drop these asserts would be a step towards cross-compiling
GHC (as opposed to building a GHC cross-compiler which still works).
* By taking clang from llvmPackages we make sure there is no version
mismatch between LLVM (where llc and opt come from) and clang (which
previously would be taken from stdenv on darwin for example).
* Only pass CLANG if useLLVM is true. Previously we also set this if
targetCC was clang. This would cause potentially confusing behavior if
llc and opt as well as clang are provided via PATH (and GHC is
compiled with useLLVM == false), because clang from PATH would be
ignored, but not llc and opt.
Since 4c75874560 it is possible to
introspect if ld.gold is contained in the used bintools, so we can also
check if it is available before deciding to use it as done in the other
GHC derivations in 0908812372.
Make clearer the difference between `maxima` and `maxima-ecl` top-level
attributes. Use the `lisp-compiler` as a passthru for all of sage's
expressions. Add the `pname` attribute for `ecl` for compatibility with
other lisp implementations.
These targets also have NCG support, but they are tested less (in fact
SPARC seems to be untested atm) and may have issues. In such cases being
able to fallback to -fllvm without rebuilding the compiler could be
useful. OTOH GHC will default to -fasm and the backends probably work
well enough in most cases.
GHC can actually accept absolute paths for its runtime tools (except for
touch) at configure time which are then saved in
`$out/lib/ghc-${version}/settings`. This allows us to drop the wrapper
entirely if we assume that a POSIX compliant touch is in PATH when we
run GHC later.
The touch problem can presumably be fixed by either patching the
configure file of GHC (although we need to take care not to change the
touch GHC uses during its compilation) or messing with the settings file
after installation.
The rationale for dropping the wrapper PATH entry completely is that
it's always possible to invoke GHC via its library which will bypass the
wrapper completely, leading to subtly different behavior.
Binary GHCs are not touched in this commit, but ideally they'll get a
similar treatment as well, so they are more robust, although we
generally don't need to use them as a library.
Note that GHC 8.8.4 doesn't care about install_name_tool or otool, so
the respective environment variables are not set.
This has two main benefits:
* GHC will work reliably outside of stdenv, even when using -fllvm since
everything it'll call at runtime will be provided in PATH via the
wrapper scripts.
* LLVM will no longer leak into haskell packages' configure
scripts. This was an issue with llvm-hs which fails to build if the
LLVM version of the compiler since the propagatedBuildInputs of GHC
take precedence over the nativeBuildInputs added in the derivation.
This brings the binary GHCs on parity with the source built ones in
terms of the wrapper. The upshot of this is that compiling something
using the binary GHCs no longer depends on PATH being populated with
the tools included in stdenv at all. We can even test this by running
the installCheck with an empty environment (via `env -i`).
Copy the approach from the normal GHC derivations for adding an
`export PATH` into the scripts in `$out/bin` and use it to put the
specific LLVM version of the binary GHC into its PATH. This will
prevent the LLVM version of the GHC we are building later to take
precedence over the LLVM version this GHC needs.
LLVM 11 libcxxabi has some flags to support usage in the Darwin stdenv,
in particular, `standalone` and `withLibunwind`.
Darwin stdenv needs the `standalone` flag because its `hostPlatform` set
doesn't have `useLLVM` set to true. And it needs `withLibunwind` to
explicitly disable including `libunwind` as a build input.
We also prefix `install_name_tool` in case we're cross-compiling.
LLVM 11 libcxxabi has some flags to support usage in the Darwin stdenv,
in particular, `standalone` and `withLibunwind`.
Darwin stdenv needs the `standalone` flag because its `hostPlatform` set
doesn't have `useLLVM` set to true. And it needs `withLibunwind` to
explicitly disable including `libunwind` as a build input.
We also prefix `install_name_tool` in case we're cross-compiling.
The libcxxabi expression had a `standalone` argument in LLVM 7 which
triggered passing of the `-DLLVM_ENABLE_LIBCXX=ON` flag. In LLVM 11 this
flag and others are toggled by the `useLLVM` attribute of
`stdenv.hostPlatform` but this toggles a flag we don't need on Darwin.
Similar to the refactoring of LLVM 7 libc++abi by Ericson2314 in
3af7e98470, I have reintroduced the standalone argument for use in
bootstrapping the Darwin stdenv.
Since we inherit the platform list from the bootstrap GHC, we get
differing lists depending on which platform we evaluate the platform
list on (depending on whether 8.10.2 or 8.6.5 is used). This leads to
Hydra thinking aarch64-linux is not supported as it evaluates on
x86_64-linux usually.
Since LLVM itself doesn't depend on target at all, this doesn't change
anything *in effect* (i. e. rebuild count should be zero), but it is
more clear about the intention and what LLVM is used for here (i. e. in
depsBuildTarget).
This means we only have to update the llvmPackages attribute in one
place now and should prevent situations like with 8.6.5 where different
versions would be used in the package set compared to the compiler
build.
Drop comments in the configuration-ghc-X.Y.x.nix files as well, since
LLVM version isn't tied to the compiler minor version at
all (e. g. 8.10.2 and 8.10.7 have different support ranges).
Without the fix build fails on gcc-12 as:
/build/llvm/lib/Target/NVPTX/NVPTXAsmPrinter.cpp:
In member function 'std::string llvm::NVPTXAsmPrinter::getPTXFundamentalTypeStr(...':
/build/llvm/lib/Target/NVPTX/NVPTXAsmPrinter.cpp:1319:10:
error: use of deleted function 'std::__cxx11::basic_string<...>; std::nullptr_t = std::nullptr_t]'
1319 | return nullptr;
| ^~~~~~~
The patch is present in upstream releases since llvm-12.
This is already done for previous versions of clang which use
a release tarball, but must be done differently for the more
recent versions which use fetchFromGitHub.
Fixes clang-tools clangd wrapper
Without the fix build on ncurses-6.3 fails as:
src/include/souffle/provenance/Explain.h:522:18: error: format not a string literal and no format arguments [-Werror=format-security]
522 | mvwprintw(queryWindow, 1, 0, prompt.c_str());
| ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
