| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
In Autoconf, some old NetBSD targets like "i686-unknown-netbsd" are
interpreted as a.out, not elf, and virtually nothing supports it. We
need to specify e.g. "i686-unknown-netbsdelf" to get the right
behaviour.
|
|
|
|
Support has landed in mainline for a while.
|
|
Newer bootloaders for RISC-V (i.e., OpenSBI + U-Boot) support
flat and compressed kernel images but not vmlinux. Therefore,
let's build "Image" like what we do with aarch64.
Also copy DTBs while we are at it.
|
|
|
|
|
|
|
|
|
|
|
|
This will begin the process of breaking up the `useLLVM` monolith. That
is good in general, but I hope will be good for NetBSD and Darwin in
particular.
Co-authored-by: sterni <sternenseemann@systemli.org>
|
|
Stating that CPUs and the isCompatible relation forms a category (or
preorder) is correct but overtly technical. We can state it more
clearly for readers unfamiliar with mathematics while retaining some
keywords to be useful to technical readers.
|
|
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.
|
|
Choose binwalk 2.3.1, 27 is legacy version for Python 2.
|
|
|
|
These are all the architectures supported by Nixpkgs on other
platforms, that are also supported by NetBSD. (So I haven't added
any architectures that are new to Nixpkgs here, even though NetBSD
supports some that we don't have.)
|
|
The previous mess was partially grouped by OS, and partially grouped
by architecture, which made it very difficult to know where to add new
entries.
I've chosen to group by OS entirely, because OSes are likely to
maintain exhaustive lists of supported architectures, but it's far
less likely we'd be able to find exhaustive lists of supported OSes
for every architecture.
|
|
|
|
Otherwise, nobody will know it's deprecated!
|
|
|
|
Deprecate the odd one so no breaking change.
|
|
|
|
lib/systems: remove powerpc64 elfv1 support
|
|
|
|
These variables are the ones that the standard toolchain uses, so we
should use those and not always use MACOSX_DEPLOYMENT_TARGET.
See https://github.com/tpoechtrager/cctools-port/blob/236a426c1205a3bfcf0dbb2e2faf2296f0a100e5/cctools/ld64/src/ld/PlatformSupport.cpp#L54-L55
|
|
Rust doesn't like the `-unknown` vendor component in the target triple.
|
|
|
|
lib/systems/platforms: remove TI_CPTS override
|
|
I was specifying the ELF ABI using -elfv1 and -elfv2 target config
suffixes, which are nonstandard and no longer work with gnu-config.
|
|
|
|
Forcing the module to be builtin breaks 5.10, which wants to compile it as a
module (probably due to dependencies). There doesn't seem to be a need to have
it builtin anymore, so we can just remove the override.
|
|
|
|
In 9c213398b312e0f0bb9cdf05090fd20223a82ad0 kernelPreferBuiltin was
moved/renamed to linux-kernel.preferBuiltin. However, for
armv7l-hf-multiplatform the new option was written with an uppercase P,
which made the kernel build process ignore it.
|
|
Enable PPC64 (big-endian)
|
|
PPC64 supports two ABIs: ELF v1 and v2.
ELFv1 is historically what GCC and most packages expect, but this is
changing because musl outright does not work with ELFv1. So any distro
which uses musl must use ELFv2. Many other platforms are moving to ELFv2
too, such as FreeBSD (as of v13) and Gentoo (as of late 2020).
Since we use musl extensively, let's default to ELFv2.
Nix gives us the power to specify this declaratively for the entire
system, so ELFv1 is not dropped entirely. It can be specified explicitly
in the target config, e.g. "powerpc64-unknown-linux-elfv1". Otherwise the
default is "powerpc64-unknown-linux-elfv2". For musl,
"powerpc64-unknown-linux-musl" must use elfv2 internally to function.
|
|
Fixes #96921
|
|
Looks like these got left behind in the
kernelArch -> linuxArch migration.
Fixes:
* pkgsCross.powernv.linuxHeaders
* pkgsCross.riscv64.linuxHeaders
* pkgsCross.riscv32.linuxHeaders
and dependees
|
|
darwin: update xcode versions
|
|
Second attempt of 8929989614589ee3acd070a6409b2b9700c92d65; see that
commit for details.
This reverts commit 0bc275e63423456d6deb650e146120c39c1e0723.
|
|
This is a stdenv-rebuild, and should not be merged
into master
This reverts commit 8929989614589ee3acd070a6409b2b9700c92d65.
|
|
The `platform` field is pointless nesting: it's just stuff that happens
to be defined together, and that should be an implementation detail.
This instead makes `linux-kernel` and `gcc` top level fields in platform
configs. They join `rustc` there [all are optional], which was put there
and not in `platform` in anticipation of a change like this.
`linux-kernel.arch` in particular also becomes `linuxArch`, to match the
other `*Arch`es.
The next step after is this to combine the *specific* machines from
`lib.systems.platforms` with `lib.systems.examples`, keeping just the
"multiplatform" ones for defaulting.
|
|
|
|
|
|
platforms.nix: Remove now unused kernelMajor
|
|
lib/systems/platforms: treat missing cpu version as generic pcBase
|
|
|
|
Since 40e7be1 all ARM platforms that didn't have a parsed cpu version
(e.g. arm-none-eabi) would be handled as armv7l-hf-multiplatform which
did break building arm-trusted-platform packages for some targets (e.g.
rk3399).
Using pcBase as fallback, instead of armv7l-hf-multiplatform,
corresponds with the behaviour we had before 40e7be1.
|
|
|
|
IA64 (Itanium) is something completely different and certainly not
what we want! x86_64 code lives in arch/x86 just like "classic" x86.
|
|
Platform config improvements
|
