| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
Also switch Linux to using the official sha1 hashes for consistency.
They are gotten from https://developer.android.com/ndk/downloads/.
|
| |
|
|
|
|
| |
This has been not touched in 6 years. Let's remove it to cause less
problems when adding new cross-compiling infrastructure.
This also simplify gcc significantly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* ppc64le enablement
* gcc, glibc: properly handle __float128
* lib/systems, stdenv: syntax cleanup
* gcc7: remove ugly hack
* gcc: add/update __float128 flags
* stdenv: add another pair of quotes for consistency
* gcc: move __float128 flag for ppc64le-glibc into common/platform-flags.nix
|
| |
|
|
|
|
|
|
| |
binutils expects x86_64-unknown-netbsd<version> (only 3 parts!). Any other combo seems to fail.
Also handle darwin versions similarly.
/cc @Ericson2314
|
| | |
|
| |
|
|
|
| |
This give us a little bit more control over what target we are using.
Eventually we can target other things like WatchOS or MacOS.
|
| |
|
|
|
| |
This version number controls which xcode version to use when building
cross to iOS.
|
| |
|
|
|
|
|
|
| |
It wasn’t exactly clear which NDK you were using previously. This adds
an attribute to system that handles what version of the NDK we should
use when building things.
/cc @Ericson2314
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Works fine without, and the 'DRM n' is actually preventing the mainline
VC4 driver from building.
|
| | |
| |
| |
| |
| |
| |
| | |
In particular, now the mainline kernel can be built on the RPi 1 as well
(so kernelBaseConfig should always be a mainline defconfig from now on).
And RPi 2 users can now use linux_rpi without doing the
`nixpkgs.config.platform = lib.systems.platforms.raspberrypi2;` dance.
|
| | |
| |
| |
| | |
A merge undid my fix in d437f2c365a12fb3894eb87f52decf53c745f475.
|
| |\ \
| | |
| | |
| | |
| | |
| | | |
Fixed conflicts:
- lib/systems/for-meta.nix: in favor of staging
- pkgs/os-specific/darwin/xcode/default.nix: in favor of master
|
| | |/
| |
| |
| |
| | |
The function value cannot be serialized so nix-env was mad. Turns out we can
just remove it like we do in `lib/systems/inspect.nix`.
|
| |\|
| |
| |
| |
| | |
Conflicts:
pkgs/top-level/all-packages.nix
|
| | | |
|
| |\| |
|
| | |\ |
|
| | | |
| | |
| | |
| | | |
Forgot to adjust default so abi with explicit float attr would be used.
|
| | | |
| | |
| | |
| | | |
(cherry picked from commit 827ef0914089e1a2bba140b49e1311eff28cc156)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There are two different official variations which differ in their float
support, so such a blanket statement is invalid.
`lib.systems.platforms.*android` already handles each case correctly.
Correcting an error in 827ef0914089e1a2bba140b49e1311eff28cc156.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This is analogous to the GNU assertion.
|
| | | |
| | |
| | |
| | |
| | | |
Function are never equal in Nix, so we need to filter out this attribute
in ABIs.
|
| | |\|
| | |
| | | |
lib: Add 32-bit Android platforms
|
| | | | |
|
| |\| | |
|
| | |\|
| | |
| | | |
lib/systems: Sort platforms, and space CPUs
|
| | | | |
|
| |\| | |
|
| | |\ \
| | |/
| |/| |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
ARM ABIs now have a float field. This is used as a fallback to lessen
our use of `platform.gcc.float`. I didn't know what the MIPs convention
is so I kept using `platform.gcc.float` in that case.
|
| |\ \ \
| | |/
| |/| |
|
| | | |
| | |
| | |
| | | |
It is ambiguous, and therefore banned within GCC.
|
| |\| | |
|
| | |\ \
| | |/
| |/|
| | | |
lib-platform-simplify
|
| | | |
| | |
| | |
| | | |
Use `parsed.cpu.name` or `platform.gcc.arch` instead.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | |/
|/| |
|
| | |
| |
| |
| | |
Whoops messed up 9a845de873dfcc31f360a08f1b1f786c6f649c7d slightly.
|
| | |
| |
| |
| |
| |
| | |
The commented-out configs are @shlevy's old known-good ones. I changed
them as needed to play nice with lib.systems.parse but did not test so
leaving them as comments for now.
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
|
| | |\
| | |
| | | |
ios-sdk-pkgs: Init from iOS SDK from XCode
|