hostArch/ARCH is ambiguous

[mahaase]

basement/plugins/multiarch.py

Lines 16 to 17 in 0d6bb3e

	elif m.startswith("aarch64"):
	return "arm64"

e.g. if we build on an aarch64 host system, we get the error, that there is no arm64-linux-gnu-toolchain. for building openssl or linux-libc-headers we need the ARCH string "arm64".

I guess we should set hostArch to aarch64 (for usage in AUTOCONF_* and because it is the result of uname -a) and map in recipes the value to arm64 if necessary.

[jkloetzke]

This is a regression introduced by c8bcf0b. The problem is that hostAutoconf now uses hostArch instead of platform.uname().machine directly...

[mahaase]

yea, but for windows, that is what we want, isn't it? so we get x86_64-pc-msys instead of amd64-pc-msys. But for arm64/aarch64 that isn't what I expect. My idea was to use in line 17: return "aarch64" so there are just some changes necessary, at least 2 changes in linux-libc-headers recipe.

[jkloetzke]

On MSYS the Autoconf triple is kind of arbitrary. Does it really need to be amd64-pc-msys?

[mahaase]

no no, that was not, what I tried to say. for windows that is okay for me! the problem is just the arm/aarch strings.

[jkloetzke]

But where do we use the ARCH variable to select a toolchain? This is not going to work. It's not documented but it's main use is the Linux kernel and other projects that adhere to it's semantics. The correct toolchain must still be selected by some other means, e.g. the CROSS_COMPILE variable.

[jkloetzke]

Ping. Changing the $ARCH value is certainly not the right approach. The correct value for "ARCH" when building for AArch64 is "arm64".

[mahaase]

i am not sure, if this was mis-usage. currently i am at this one: #78
if this problem here will come back in my mind, i'll "pong" it.