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.
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
(cherry picked from commit ba52ae50488de85a9cf60a3a04f1c9ca7122ec74)
At the upstream URL at http://git.uclibc.org/uClibc/snapshot/, older
versions are dropped at a regular basis. Unfortunately the tarball
"uClibc-20150131.tar.bz2" has already been deleted from that directory
and I didn't find a mirror providing the same file.
So I've switched it to use fetchzip from the cgit site instead of using
fetchgit directly. The reason why I didn't use fetchgit is that we'd
need need git, which depends (indirectly? not sure, haven't checked) on
libiconv and that in turn triggers an assertion if we're on Linux and
are cross-building using uclibc.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I also update the way the configuration is generated, so it works for
our ARM EABI, armv5tel.
We will have to enable the FPU for armv6 and beyond.
Conflicts:
pkgs/os-specific/linux/uclibc/default.nix
or gcc fails to build (lack of pthread.h).
Let's see if this breaks anything; I'm changing this to make comtrend.nix work
(kernel 2.4).
svn path=/nixpkgs/trunk/; revision=34227
armv5tel-unknown-linux-gnueabi/libstdc++-v3/include/cstdio:133:11: error: '::tmpnam' has not been declared
http://hydra.nixos.org/build/2644907
svn path=/nixpkgs/trunk/; revision=34226
cross-building nixpkgs implementation, were not referenced anywhere.
This new busybox builds natively, and also cross-builds with uclibc.
I updated the uclibc config with a busybox defconfig requirement (something about RPC).
I made the gcc-cross-wrapper properly set the dynamic loader to programs.
After this, 'qemu-arm' can run the dynamically linked busybox cross built for armv5tel--linux-gnueabi.
svn path=/nixpkgs/trunk/; revision=20514
This involved fixing some buildInputs/buildNativeInputs in acl/attr,
and adding a libiconv in some places.
svn path=/nixpkgs/branches/stdenv-updates/; revision=20510
between uclibc/glibc still.
I started the renaming from glibc to libc regarding the cross-toolchain, but I
still have to finish.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18801
