remove unused hostInfo variable, the uses of it were removed in (androidndk: remove legacy ndks)[2408ef3c6f].
This prevents exiting with `error "attribute 'triple' missing"`
It's better to exit with a throw than a attribute missing which cannot
It's better to exit with a throw than a attribute missing which cannot
be caught with tryEval
```
> pkgsCross.aarch64-android-prebuilt.androidndkPkgs
error: attribute 'androidndkPkgs_21' missing
```
Proper ways to to use `androidndkPkgs` AFAIK.
`with import ./. { crossSystem = (import ./lib).systems.examples.aarch64-android-prebuilt; }; buildPackages.androidndkPkgs`
or
`pkgsCross.aarch64-android-prebuilt.buildPackages.androidndkPkgs`
We add -pie if we don't find -shared in the arguments. However this does not
work in the presense of @response files. We also do not respect -no-pie, and
add -pie regardless. This improves the argument parsing, and allows to prevent
the forced -pie flag.
Without this patch ghc 8.10.7 with taget platform aarch64-android fails
to build due an invalid nix expression (missing attribute targetPrefix).
To fix that we make the binaries attribute to conform with the
expectation about unwrapped bintools / cc derivations w.r.t. passthru
attributes.
It is useful to make these dynamic and not bake them into gcc. This
means we don’t have to rebuild gcc to change these values. Instead, we
will pass cflags to gcc based on platform values. This was already
done hackily for android gcc (which is multi-target), but not for our
own gccs which are single target.
To accomplish this, we need to add a few things:
- add ‘arch’ to cpu
- add NIX_CFLAGS_COMPILE_BEFORE flag (goes before args)
- set -march everywhere
- set mcpu, mfpu, mmode, and mtune based on targetPlatform.gcc flags
cc-wrapper: only set -march when it is in the cpu type
Some architectures don’t have a good mapping of -march. For instance
POWER architecture doesn’t support the -march flag at all!
https://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html#RS_002f6000-and-PowerPC-Options
New android ndk (18) now uses clang. We were going through the wrapper
that are provided. This lead to surprising errors when building.
Ideally we could use the llvm linker as well, but this leads to errors
as many packages don’t support the llvm linker.
