There are builds which rely on having the numeric version of gcc (eg "10.2.1")
declared in an environment variable.
Running 'arm-none-eabi-gcc --version' returns:
"arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release)"
However, the attribute arm-none-eabi-gcc.version is "10-2020-q4-major",
from which there is no way to derive "10.2.1".
Contrast this with the attribute gcc.version which (at this time) gives "10.3.0".
By adding a numVersion attribute, consumers of this package can
correctly determine what GCC version is being executed.
Signed-off-by: Sirio Balmelli <sirio@b-ad.ch>
In a few cases it wasn't clear so I left them as-is.
While visiting these moved other things to nativeBuildInputs
when it was clear they were one of these cases:
* makeWrapper
* archive utilities (in order to unpack src)
* a few of these might no longer be needed but leaving for another day
According to https://launchpad.net/gcc-arm-embedded:
> Licence:
> Simplified BSD Licence, GNU GPL v2, GNU GPL v3, GNU LGPL v2.1, GNU
> LGPL v3, MIT / X / Expat Licence
Seems that GCC ARM Embedded have changed convention for file location,
and version 5.2 isn't accessible from the predicted url. That's why
nix-expression is updated to allow overloading url parts.
The $lib output refers to the terminfo database in $out, which is about
10x larger than the ncurses shared library. Splitting these outputs
saves a small amount of space for any derivations that use the terminfo
database but not the ncurses library, but we do not have evidence that
any such exist.
Fixes this:
$ arm-none-eabi-gdb
arm-none-eabi-gdb: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory
These are packages for precompiled ARM microcontroller compilers from
https://launchpad.net/gcc-arm-embedded.
[Bjørn: modify commit message (add paragraph).]
