Live data from Hacker News

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

rachelbythebay.com

1–10 of 150 posts

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

#4
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!

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

#8

[flagged]

It's not explicitly stated but in her reproduction she is actually running it on the pi, and compilers very much do normally compile for the arch that they are running on by default.

A compiler which compiles for a different arch is called a cross-compiler. Unless you explicitly asked for a cross compile, it is indeed surprising for a compiler to emit a binary that won't run on the same machine.

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

#10
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.

Post reply on HN