This package doesn't seem to be updated consistently so adding an updateScript so the bot will create PRs when linux_latest is bumped to a new branch version.
Without the change builx of `pkgsi686Linux.linuxHeaders` fails on my
`btrfs` with 64-bit inodes as:
linux-headers> fixdep: error fstat'ing file: scripts/basic/.fixdep.d: Value too large for defined data type
Normally `Kbuild` attempts to pass correct LFS flags by extracting
them from `getconf` as:
HOST_LFS_CFLAGS := $(shell getconf LFS_CFLAGS 2>/dev/null)
But `nixpkgs` does not provide it and the build fails.
The change hardcodes LFS flags for 32-bit systems.
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build https://github.com/infinisil/treewide-nixpkgs-reformat-script/archive/a08b3a4d199c6124ac5b36a889d9099b4383463f.tar.gz \
--argstr baseRev 78e9caf153
result/bin/apply-formatting $NIXPKGS_PATH
compared output and the build log and python2 is not required
both build
'pkgsCross.aarch64-android.linuxHeaders'
'pkgsCross.aarch64-android.bionic.linuxHeaders'
linux-headers> LEX scripts/kconfig/lexer.lex.c
linux-headers> sh: line 1: flex: command not found
linux-headers> YACC scripts/kconfig/parser.tab.[ch]
linux-headers> sh: line 1: bison: command not found
linux-headers> INSTALL ./usr/include
linux-headers> sh: line 1: rsync: command not found
Co-authored-by: exarkun <exarkun@twistedmatrix.com>
mips tools require endian headers which are different on darwin.
Add stub headers to define the appropriate byte swap functions.
Co-authored-by: Adam Joseph <54836058+amjoseph-nixpkgs@users.noreply.github.com>
Without it openiscsi build fails in staging-next as:
../../include/iscsi_proto.h:550:9: error: unknown type name 'itt_t'
550 | itt_t itt; /* Initiator Task Tag */
| ^~~~~
Very confusingly, the `isPowerPC` predicate in
`lib/systems/inspect.nix` does *not* match `powerpc64le`!
This is because `isPowerPC` is defined as
isPowerPC = { cpu = cpuTypes.powerpc; };
Where `cpuTypes.powerpc` is:
{ bits = 32; significantByte = bigEndian; family = "power"; };
This means that the `isPowerPC` predicate actually only matches the
subset of machines marketed under this name which happen to be 32-bit
and running in big-endian mode which is equivalent to:
with stdenv.hostPlatform; isPower && isBigEndian && is32bit
This seems like a sharp edge that people could easily cut themselves
on. In fact, that has already happened: in
`linux/kernel/common-config.nix` there is a test which will always
fail:
(stdenv.hostPlatform.isPowerPC && stdenv.hostPlatform.is64bit)
A more subtle case of the strict isPowerPC being used instead of the
moreg general isPower accidentally are the GHC expressions:
Update pkgs/development/compilers/ghc/8.10.7.nix
Update pkgs/development/compilers/ghc/8.8.4.nix
Update pkgs/development/compilers/ghc/9.2.2.nix
Update pkgs/development/compilers/ghc/9.0.2.nix
Update pkgs/development/compilers/ghc/head.nix
Since the remaining legitimate use sites of isPowerPC are so few, remove
the isPowerPC predicate completely. The alternative expression above is
noted in the release notes as an alternative.
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
This PR adds a new aarch64 android toolchain, which leverages the
existing crossSystem infrastructure and LLVM builders to generate a
working toolchain with minimal prebuilt components.
The only thing that is prebuilt is the bionic libc. This is because it
is practically impossible to compile bionic outside of an AOSP tree. I
tried and failed, braver souls may prevail. For now I just grab the
relevant binaries from https://android.googlesource.com/.
I also grab the msm kernel sources from there to generate headers. I've
included a minor patch to the existing kernel-headers derivation in
order to expose an internal function.
Everything else, from binutils up, is using stock code. Many thanks to
@Ericson2314 for his help on this, and for building such a powerful
system in the first place!
One motivation for this is to be able to build a toolchain which will
work on an aarch64 linux machine. To my knowledge, there is no existing
toolchain for an aarch64-linux builder and an aarch64-android target.
Maximilian Bosch