* The final installation was not at the correct place; looks like
the DESTDIR that worked previously needs to be PREFIX now.
* Make tests work. These aldo didn't run anymore even though it
looked they might've in the past.
For that, add a bunch of local Perl packages needed by these
tests that were not available in nixpkgs yet (Plan is to move
them to perl-packages.nix, but as first step have them local
here to have a self-contained z88dx.
See https://github.com/llvm/llvm-project/pull/100804 for further
context.
Tests for LLVM 12 to 16 pass fine without this change (the entire
section of the test doesn't exist there), our LLVM 19 already has the
patch applied.
Fixes
/nix/store/8pq96x5qsczrmc926795lf7j4dzy2c8q-binutils-patchelfed-ld-2.43.1/bin/ld: ../../src/liblzma/.libs/liblzma.so: undefined reference to `__pthread_cond_timedwait64'
collect2: error: ld returned 1 exit status
while building `xz` for `stdenv`. The root cause is that glibc replaced
`__USE_TIME_BITS64` with `__USE_TIME64_REDIRECTS`[1]. However, the
stage3 GCC seems to use the bootstrap headers from glibc for
`fixincludes`, i.e. headers w/o this change. Because of that, the xz
build with stage3 stdenv gets a header that looks like this:
# ifndef __USE_TIME_BITS64
/* ... */
# else
# ifdef __REDIRECT
/* ... */
# else
# define pthread_cond_timedwait __pthread_cond_timedwait64
# endif
# endif
Since __USE_TIME_BITS64 doesn't exist anymore because a new glibc is used
for building, the preprocessor ends up in the condition defining
`__pthread_cond_timedwait64` even though it's not supposed to end up
there since __pthread_cond_timedwait64 doesn't exist on x86_64[2].
I decided to just kill the header here since GCC claims that all the
`pthread.h` only very old glibc versions or platform-specific libcs we
don't use[3].
[1] https://sourceware.org/git/?p=glibc.git%3Ba%3Dcommit%3Bh%3Ddd535f4f19ef2b5c367a362af445ecadcf45401e
[2] https://inbox.sourceware.org/libc-stable/50c0269d-b73c-4e8a-9816-65f72d6082c0@linaro.org/
[3] https://github.com/gcc-mirror/gcc/blob/releases/gcc-14.2.0/fixincludes/inclhack.def
cmake flags have a 'last flag wins' logic, so by appending to the end of
the flags it is possible to override any cmake flag.
It also ignores (and warns) if a flag is unused, so passing flags across
all packages should be safe if you want to target one package.
In combination with #320261, this PR allows consistently overriding all
packages within LLVM with additional cmake arguments. Consistency here
means for example 'if you override LLVM, then all dependencies on it are
also see the overridden LLVM in their input'. Consistency is hard to
achieve with the other obvious way of implementing this as a user: if
you use overrideAttrs then you have to write a big mess of override code
in order to override all dependents, and this can be very difficult in a
cross-compilation scenario using crossSystem and useLLVM, for example.
With this PR it is possible to write an overlay which overlays
`llvmPackages` with `llvmPackage.override { devExtraCmakeFlags = [ ... ]; }`,
and then the toolchain used with useLLVM in effect should respect
these flags.
This is useful in development for experimenting with the effect of
various flags, hence the chosen name `devCmakeFlags`.
This won't work out of the box without #341855 applied, which fixes
override passthrough.
See-Also: #320261, #341855
Signed-off-by: Peter Waller <p@pwaller.net>
Pull #320261 introduced the possibility to consistently override
dependencies within an llvm package set. I think #325175 accidentally
dropped this, so reinstate it.
Signed-off-by: Peter Waller <p@pwaller.net>
The Darwin LLVM backend of GHC (which is mostly interesting for
GHC < 9.2) uses clang as configured via the CLANG environment variable
as an assembler. Since it processes outputs of clang as configured via
the CC variable, we need to make sure these versions match or risk CLANG
clang not understanding the output of CC clang.
In the past this wasn't really a problem as due to the fairly old
default clang version in the stdenv, clang 11 would be used for CC.
CLANG would always be a newer version and deal with the output without
any problems.
Ever since the upgrade of the default clang version for
darwin (bcbdb800cf), CC would often be a
newer version of clang than CLANG, causing build problems in some
packages like crypton (for GHC 8.10.7 and 9.0.2 on aarch64-darwin where
the darwin LLVM backend was actually used).
