-B must be set to the root directory of avrlibc, otherwise gcc cannot
locate crt objects for some attiny devices. -L trains as set by
bintools-wrapper are not necessary with -B set correctly because gcc
takes care of that, and likewise we can drop the -B train from
cc-wrapper because the one spec is enough.
In https://github.com/NixOS/nixpkgs/pull/266364/files I neglected to
evade one of newlib's other (annoying) self-disablement checks: when
host==target newlib decides it's not in the mood to build itself for
some reason.
Since we have an entire package for newlib (it's no longer part of
gcc) these checks are silly. So I have evadede the second check as well.
Closes#267859
The newlib configury uses `host` to refer to the platform which is
being used to compile newlib. Ugh. It does this because of its
history: newlib used to be distributed with and built as part of
gcc.
To prevent nixpkgs from going insane, this package presents the
"normal" view to the outside world: the binaries in $out will
execute on `stdenv.hostPlatform`. We then fool newlib's build
process into doing the right thing.
This continues where d8f7f6a5ce left off. Similarly
to that commit, this commit this also points `sourceRoot`s to `src.name` and similar
instead of keeping hardcoded names, and edits other derivation attrs do do the same,
where appropriate.
Also, similarly to d8f7f6a5ce some of expressions this
edits use `srcs` attribute with customly-named sources, so they have to be moved
into `let` blocks to keep evaluation efficient (the other, worse, way to do this
would to recurcively refer to `elemAt n finalAttrs.srcs` or, similarly, with `rec`).
librdimon.a is only available on ARM architectures, therefore building
newlib-nano for other architectures (e.g. RISC-V) fails presently.
This commit fixes this issue by only copying the library files that
actually exist in the for loop body. Alternatively, it would be
theoretically feasible to change the libraries iterated over based
on the targeted architecture.
One of resholve's passthru tests depended on getting `script` from
util-linux, but it's no longer there on macos after #232713.
This change just tracks upstream change to use unixtools.script, which
is what I should have used in the first place. Upstream commit for
reference:
3407150949
