Support RPi-Zero (armv6h)

[duncanmead]

Hi. I am trying to install ashuffle on a Raspberry pi zero. I already had libmpdclient2 installed (version 2.16-1). When I run ./ashuffle.armv6h-linux-gnueabihf I receive an error message "Segmentation fault". I also get this if I run as root. I'm sure that I am doing something wring, but I can't work out what.

Any ideas?

Thanks.

Duncan

[joshkunz]

Well that's a bummer, that definitely shouldn't happen.

Unfortunately I don't have a raspberry pi zero to test on so this may take a while to fix. The only option for me to verify would be using an emulator.

Some things you can do/try in the meantime that would be helpful are:

• Provide what version of Raspbian/other OS are you running.
• If you know how, run the binary under gdb, and paste the output of the bt command after the segfault.
• You can always try building from source though you may have a hard time on a pi zero.
• If you want to try cross-compiling yourself, the scripts we use to build the armv6h binaries can be found: here.

[duncanmead]

Hi. Apologies for the delay in replying.

Version: Linux version 5.4.51+ (dom@buildbot) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1333 Mon Aug 10 16:38:02 BST 2020
(Raspbian Buster)
I installed gdb on the Pi, but I cannot find a way to run this locally.

Thanks for your reply, but I will probably find another way to do this without ashuffle.

Duncan

[joshkunz]

Good luck finding an alternative solution. I'm going to re-open this though to track finding a fix for this issue.

It looks like raspberry pi zeros are actually pretty cheap so I picked one up. I'll take a look at this when I have some time.

[joshkunz]

Ugh, so I was able to reproduce this on a Pi zero. For the armv6h binaries, I was building using Linaro's ARM32 cross-compiler. Unfortunately that has a few issues for RPi-Zero:

• The glibc bundled with the toolchain is newer than the one distributed with raspbian. That's probably what was causing the SEGFAULTs.
• Unfortunately, even with a downgraded toolchain we still run into SIGILL (illegal instruction) faults. Turns out the Linaro toolchain is built for armv7-a, so the startup files (crt*.o) are the wrong architecture, and we fault on startup.

Ultimately I think the only fix for this is for us to build our own cross toolchain unfortunately... Renaming this and leaving it open. I'll send a PR to remove the binaries (and documentation) to avoid confusion.

[martinetd]

Ultimately I think the only fix for this is for us to build our own cross toolchain unfortunately... Renaming this and leaving it open. I'll send a PR to remove the binaries (and documentation) to avoid confusion.

I'd be surprised there's no generally-available toolchains for the various raspberry platforms -- a quick search got me https://github.com/Pro/raspi-toolchain which appears to build for armv6 properly looking at the dockerfile so the released binaries should be ok. It also requires a raspbian rootfs for compatibility so it's a bit more work perhaps but more likely to work.

(Not tested as I don't have any readily-available around; I don't think it'd be that bad to build directly on one either but I might be underestimating how small the pi zero is)

[joshkunz]

@martinetd That is fair, thanks for the pointer.

I also searched a bit and found abhiTronix/raspberry-pi-cross-compilers which looks pretty active as well. Thinking more about it, I also remembered that lots of distros actually package cross-compilers, so we may be able to just use one of those (probably via docker container so it can be easily reproduced locally). I know QEMU actually uses this approach for their unit-test suite.

I don't think it'd be that bad to build directly on one either but I might be underestimating how small the pi zero is.

This thing is tiny. With the default install, chrome was idling at like 60% CPU usage. If we tried to build that way it would be extremely slow. There was at least one user that tried and ran into OOM issues. Plus I don't really want to try and host the build infra, I'd much rather build on Travis directly.

[joshkunz]

So, I've got a cross-build of ashuffle running on the RPi Zero. I ended up going with the approach of just using a pre-packaged clang with an actual RPi OS image as the sysroot. Turns out RPi OS actually packages functional gcc toolchain libraries in the root fs. Only issue I ran into, was that RPi OS is still using libstdc++6 which lacks several C++17 library features that we currently use in ashuffle: std::optional, std::variant, and std::string_view. Abseil provides drop-in C++14-compatible versions of these classes, so I was able to switch to the Abseil versions without too much trouble.

I don't love downgrading the language version just to support RPi Zero though. I think before merging the downgrade, I will actually try to get a newer C++ stdlib and do a static link. I'll either try and pull one from a deb if available, or cross-build LLVM's libc++ myself. If that doesn't work or is extremely painful I'll just go with the downgrade.

[joshkunz]

The release tooling fixes from PR #86 has been released as v3.10.0.