from Hacker News

Clang now makes binaries an original Pi B+ can't run

by FPGAhacker on 12/3/23, 2:07 AM with 137 comments

• by stephen_g on 12/3/23, 7:07 AM

  Wow, looking at the history of the ARM generation the original versions of the Raspberry Pi uses, it’s hard to believe it’s so old! When the Raspberry Pi B+ was released (2014), the ARM core it used was already 11 years old (using the ARM1176 core from 2003). So it’s not unbelievable that you might need to start supplying an arch flag to produce compatible code building on a different platform (like the newer Raspberry Pi the article says they first built on).

  As others have said, it does seem like a misconfiguration (perhaps in the defaults shipped by their distribution) that the correct arch is not picked by default when building on the Raspberry Pi B+ itself.

• by schemescape on 12/3/23, 6:23 AM

  I didn't see it addressed here or in the article: this is a bug, right?

  Edit: oddly, after searching LLVM bugs, I found a bug that sounds pretty much exactly like this issue... but it's from 2012 and is closed (although the final couple of comments make it sound like maybe it wasn't actually fixed--note: I only skimmed the comments and I probably misunderstood):

  https://github.com/llvm/llvm-project/issues/13989

  Edit again: I forgot about the comment at the end of the article that clarifies that explicitly passing the target results in a working program. In that case, it sounds like some sort of configuration bug--I would assume (but am not certain) that the default target would be the current processor, at least on Unix. That bug I linked was probably about producing incorrect code even when the target was set correctly which, thankfully, isn't happening today.

• by rschu1ze on 12/3/23, 5:52 PM

  The database I work on (ClickHouse) tries hard to stay compatible with really old hardware. The standard ARM binaries require Armv8.2 from 2016 (available in Raspberry Pi 2 >=2) and x86 binaries run on hardware from around 2010 (SSE4.2 + pclmul* instructions for fast CRC). We also build (but don't test using CI) binaries for Armv8.0 and SSE2-only systems. A quick install script downloads and unpacks the right binary for the target host.

  I find it generally hard to strike a good balance between backwards compatibility and usage of modern CPU features in newer AArch64 generations (https://en.wikipedia.org/wiki/AArch64). We found that there are surprisingly many institutions on a shoestring budget (universities in emerging countries) or hobbyists that can't afford to upgrade their hardware.

  On a technical note, what I found quite cumbersome is that the cpu flags in /proc/cpuinfo don't always correspond with the flags passed as -march= to the compiler, e.g. "lrcpc" vs "rcpc". To make all of this work, one really needs to maintain two sets of flags.

• by opello on 12/3/23, 9:18 AM

  Seems like the problem is likely a configuration target change in the clang-13 package that's current for bookworm.

  Specifically because under bullseye (and clang-11) the default target is armv6k-unknown-linux-gnueabihf while under bookworm (and clang-13) the default target is arm-unknown-linux-gnueabihf.

  Or maybe the default changed for the given build configuration on the LLVM side?

• by JonChesterfield on 12/3/23, 10:44 AM

  I doubt this is a deliberate change. Picking up information from the environment - a sibling mentions /etc/env.d/gcc - seems fairly likely. I'd guess the default triple is something like arm-unknown-linux unless clang finds or is is told something more specific to use, and the mechanism by which it gets told to use something more specific has fallen over.

  This might mean there are no arm v6 buildbots running, or it might mean there are ones running but the implicit configuration is still working on them.

  LLVM is a really good cross compiler. Build for any target from any target, no trouble. Clang is less compelling - if it's built with the target, and you manage to tell it what target to build for, it'll probably do the right thing (as in this post - it guessed wrong, but given more information, did the right thing). Then the runtime library story is worse again - you've built for armv4 or whatever, but now you need to find a libc etc for it, and you might need to tell the compiler where those libraries and headers are, and for that part I'm still unclear on the details.

• by matja on 12/3/23, 7:33 AM

  clang/clang++ read from /etc/env.d/gcc to get the target flags/profile, it's up to the OS to maintain them and make sure they're correct, looks like that didn't happen for this OS.

  My Gentoo ARM SBC based on an even more ancient armv4 arch has been chugging along just fine with the latest gcc/clang updates:

      grep CTARGET /etc/env.d/gcc -r
      /etc/env.d/gcc/armv4tl-softfloat-linux-gnueabi-11.3.0:CTARGET="armv4tl-softfloat-linux-gnueabi"

• by cbmuser on 12/3/23, 4:13 PM

  The article doesn’t mention whether Debian or Raspian was installed. And, in case of Debian, whether the armel or armhf port is being used.

  Without that information, it’s pretty pointless to make claims about the instruction set LLVM compiles to because that’s a matter of what native target LLVM has been configured for.

  FWIW, in Debian, llvm-toolchaim-snapshot still supports armel which uses ARMv5T as the baseline (there is currently an unrelated bug in LLVM’s OpenMP library though which prevents a successful build).

• by teddyh on 12/3/23, 6:15 AM

  It would probably be helpful to know the output of the command “dpkg-architecture” and the contents of the file “/etc/os-release”. Otherwise it will be hard to make any useful comments.

• by fsniper on 12/3/23, 11:02 AM

  Title is unfortunately sensational. This is a default target change. Turns out clang still can build binaries for the Pi B+. You just need to be explicit about the architecture. So perhaps a small title change that's more clear about this being only default setting change?

• by sovietmudkipz on 12/4/23, 1:02 AM

  Oh cool so this is kinda how one might debug why a program isn’t running on arm. I have a Unity Linux build that I can’t get running inside a container. Unity mono is trying to make a system call that isn’t available, even after passing in the amd64 flag to docker when running the container.

  I haven’t debugged it because I found a work around (enable development mode, change build settings so mono isn’t used). I should return to it at some point, just to learn more.

• by vkaku on 12/3/23, 8:10 PM

  clang has been broken for a while in the last few versions. Many issues were left unfixed and development moved to 17.0.0 when they should have fixed those as point releases for 16.0.x instead (patches were available and not integrated).

  In this particular case though, the end processor/native detection seems to be failing and clang feature detection gets armv7l as native (or could just be the default generation option). Looks like a good bug to report, if only we get the good clang folks who will take the time to land a fix.

  I have been playing around with zig. My current focus will be on not using broken compiler backends for a while.

• by frizlab on 12/3/23, 6:13 AM

  Title is misleading

• by johnklos on 12/3/23, 6:15 AM

  You'll see a whole bandwagon of people saying things like, "supporting old hardware is BAD! It takes time and money that nobody has!", as though someone needs to be hired to sit around and do nothing but pore over code and constantly rewrite code for old hardware.

  There's plenty of evidence to the contrary, but since when has evidence mattered when it comes to defending the right of big business / big distro to do whatever they want? ;)

  Really, this is just laziness and sloppiness on the Linux distro makers' part. Any amount of testing would catch this. Thanks, Rachel!

• by 1vuio0pswjnm7 on 12/3/23, 8:49 PM

  "I guess nobody still runs these old things anywhere?"

  I have one running BSD UNIX-like OS as I type this comment.

• by auselen on 12/3/23, 8:20 AM

  Confused article? You make a host/native build instead of cross and expect it to work on some other machine?