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 ba52ae5048)
Semi-automatic update. These checks were performed:
- built on NixOS
- found 1.11.0 with grep in /nix/store/m55my69q0dc6rbvf7sfz3mln7vca1d53-seabios-1.11.0
- found 1.11.0 in filename of file in /nix/store/m55my69q0dc6rbvf7sfz3mln7vca1d53-seabios-1.11.0
cc "@tstrobel"
Semi-automatic update. These checks were performed:
- built on NixOS
- found 2.4 with grep in /nix/store/5p43l2r5y6m0sdpyxwcwiv381ycglami-remotebox-2.4
- found 2.4 in filename of file in /nix/store/5p43l2r5y6m0sdpyxwcwiv381ycglami-remotebox-2.4
The AArch64 build fails after trying to pull in tmmintrin.h:
```
../common/memcpySSE.h:24:23: fatal error: tmmintrin.h: No such file or directory
#include <tmmintrin.h>
^
compilation terminated.
make: *** [Makefile:29: .build/renderers/opengl.o] Error 1
```
Which are SSSE3 intrinsics unsupported on ARM. This package also likely would
not be useful on ARM, as it requires KVM and a compatible KVM guest running
the frame relay (usually Windows).
Upstream changes without issue IDs:
* GUI: fixed occasional screen corruption when host screen resolution
is changed
* User interface: increase proposed disk size when creating new VMs for
Windows 7 and newer
* User interface: various improvements for high resolution screens
* VMM: Fixed problems using 256MB VRAM in raw-mode VMs
* Audio: implemented support for audio playback and recording for macOS
guests
* Audio: further timing improvements for Windows 10 guests
* Linux hosts: fixed problem accessing mini-toolbar under XFCE
The full changelog including issue IDs can be found at:
https://www.virtualbox.org/wiki/Changelog#v6
What was not mentioned in the changelog is that this release fixes
compiling the VirtualBox modules against kernel 4.15, which was added in
commit 61043ad4d1.
Tested this by running all of the tests in nixos/tests/virtualbox.nix.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @flokli, @svanderburg
[...]
make modules -C /nix/store/h1vzl6bq4wif3m8dd1bw2p3fv4shjg3n-linux-4.14.9-dev/lib/modules/4.14.9/build EXTRA_CFLAGS=-Werror-implicit-function-declaration M=/tmp/nix-build-spl-kernel-2017-11-16-4.14.9.drv-0/source/build
/nix/store/h1vzl6bq4wif3m8dd1bw2p3fv4shjg3n-linux-4.14.9-dev/lib/modules/4.14.9/source/Makefile:939: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel". Stop.
This patch introduces kernel.moduleBuildDependencies to avoid the logic "stdenv.lib.optional (stdenv.lib.versionAtLeast kernel.version "4.14") libelf" in multiple places.
[dezgeg did some minor tweaks on top]
