arm64/aarch64 support?

[palfrey]

Is there any interest in contributing support for this architecture? I'd be intending on getting this up and running on a Pinebook Pro (which I don't own yet, but intend on purchasing soon).

If so, any thoughts on naming? I'm leaning towards arm64 myself (the two names and reasons behind that is explained at https://stackoverflow.com/a/31852003/320546).

[stapelberg]

I don’t have any arm64 computers on which I want to run distri, so I won’t spend time on this myself.

distri already knows how to cross-compile (a select handful of packages) for i686, so I suppose adding arm64 support into the tooling would not be too difficult.

The remaining work is largely building packages for arm64 and applying build.textproto changes and possibly patches to make them build/work correctly.

If someone wanted to contribute that work, I would be happy to help review it and answer questions.

[palfrey]

#71 fixes the core issues I've had so far, but I've been having some weird issues building bash.

I'm using the command line distri build -cross=arm64 -hermetic=false -pkg=bash running in a Debian Vagrant box (as my current desktop is OS X, so can't do the compile there) and I keep running into the issue that /usr/src/bash-arm64-5.0-4/lib/glob/smatch.c for some reason has the permissions 600 and nobody/nogroup.

Attempting to hack around this and change the permissions gets me chmod: changing permissions of '/usr/src/bash-arm64-5.0-4/lib/glob/smatch.c': Value too large for defined data type which is a deeply fun error. Have you seen this sort of thing before? Any hints?

[stapelberg]

Huh, this does not ring a bell. I can try to take a look tomorrow.

[stapelberg]

Which Linux kernel version are you running on? uname -r

I’m testing with Linux kernel 5.5.8 on Arch Linux, and for me, your command works:
build log

I also checked the file type, and it looks correct to me:

/ro/bash-arm64-5.0-4/out/bin/bash: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=245c792dc15f9f84cc8680e0aae9be5d9496edb6, for GNU/Linux 3.7.0, with debug_info, not stripped

[palfrey]

I've managed now to track down the issue: Vagrant shared folders. Default didn't work, switching to rsync type now works. Or at least it gets as far as as the musl-gcc wrapper step and I'm looking now at getting that working for cross compiling.

[stapelberg]

Ah, great.

By the way, I think you’ll eventually need a cross-compiler package setup like the gcc-i686* packages, but for arm64.

[stapelberg]

An additional difficulty in cross-compilation is that your system should be set up to execute arm64 programs: https://ownyourbits.com/2018/06/13/transparently-running-binaries-from-any-architecture-in-linux-with-qemu-and-binfmt_misc/. This is needed e.g. for building bc

This is a little easier when cross-compiling for i686, which typically runs fine on amd64.

[palfrey]

Thanks. So #72 fixes the cross-platform support for musl-gcc, and I've managed to build the bash package :)

[palfrey]

#73 adds cross-arch building to batch, but I'm running into issues running batch as it defaults to a hermetic build which doesn't work very well for cross-building. Would you be interested in a patch to allow for non-hermetic builds for batch?

[palfrey]

Also it would be useful for my purposes to have a flag for batch to make it die on the first build failure (defaulting to current "keep going" mode). Is a patch that does that of interest?

[stapelberg]

#73 adds cross-arch building to batch, but I'm running into issues running batch as it defaults to a hermetic build which doesn't work very well for cross-building. Would you be interested in a patch to allow for non-hermetic builds for batch?

I recommend doing non-hermetic builds only for the bootstrap set of packages. I have pushed commit e535899 which should illustrate how I’ve been doing bootstraps thus far.

Once you have those built non-hermetically, you can rebuild them hermetically, then build the rest.

This strategy should be far less error-prone than doing many non-hermetic builds.

[stapelberg]

Also it would be useful for my purposes to have a flag for batch to make it die on the first build failure (defaulting to current "keep going" mode). Is a patch that does that of interest?

Yep, that sounds reasonable.

[palfrey]

#75 adds cross-building support to glibc, but beyond that I'm starting to run into issues. Major fun one is things that depend on gmp (mpfr/mpc) which want to load the gmp.h, which if they load the system one results in them using the system gcc :(

Given all of that, I think that cross-platform bootstrap would need a lot more work, and so I'm going to wait until my Pinebook Pro turns up before doing more work on this on a native system.

[stapelberg]

Yeah, I don’t know a solution to that off the top of my head either.

Do let me know if you’re stuck on this once you resume work, and we can take a closer look.

[junland]

I don’t have any arm64 computers on which I want to run distri, so I won’t spend time on this myself.

@stapelberg ARM has a project that you can submit a request to get access to ARMv8 / aarch64 servers should be here.

[palfrey]

Having another go at this today on the Pinebook, and urgh. Getting fun errors like error: ‘_Float128’ is not supported on this target while trying to compile glibc (using stock Debian gcc 9.3.0). Spent a while googling around to see if anyone else hit this one, and no luck so far.

[stapelberg]

@stapelberg ARM has a project that you can submit a request to get access to ARMv8 / aarch64 servers should be here.

That’s good to know, but it doesn’t change my position: I don’t have any ARM hardware myself on which I’d want to run distri, so I’m not motivated to work on this actively :)

[junland]

@stapelberg ARM has a project that you can submit a request to get access to ARMv8 / aarch64 servers should be here.

That’s good to know, but it doesn’t change my position: I don’t have any ARM hardware myself on which I’d want to run distri, so I’m not motivated to work on this actively :)

No worries, just a suggestion. Just following this project :)

Having another go at this today on the Pinebook, and urgh. Getting fun errors like error: ‘_Float128’ is not supported on this target while trying to compile glibc (using stock Debian gcc 9.3.0). Spent a while googling around to see if anyone else hit this one, and no luck so far.

@palfrey You might want to change your gcc options and add --enable-fix-cortex-a53-835769 --enable-fix-cortex-a53-843419. That's assuming that your creating a new compiler and using that to compile glibc. I ran into the problem too however I kinda forgot how I fixed it. Granted I was cross compiling on amd64.

EDIT: Actually, @palfrey you should add --disable-werror to glibc came across it again when trying todo aarch64 and was able to solve it with that flag. Hope that helps.