Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

rachelbythebay.com

Post reply on HN
Print view View original

51–60 of 150 posts

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

#51

Post by woodruffw »

johnklos wrote: post #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 wh…

This has nothing to do with the distro; it looks like an upstream LLVM bug. And it does demonstrate the problem: old code doesn’t change, but interfaces and invariants do. Those external changes do represent maintainer burden.

Armv6 isn’t really “old hardware” in the “disused, actively rotting” sense. That’s reserved for things like Itanium or HPPA, which distributions (and upstreams) would do perfectly well to remove unless paid buckets of money by their respective corporations.

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

#52

Post by ninepoints »

amatecha wrote: post #17
ninepoints wrote: post #6

[flagged]

Uh, what? It's weird to assume "clang++ -Wall -o t t.cc" should produce a binary that runs on the architecture we're currently using?

You think most clang devs test on pre arm7 architectures? (And I don't mean in a cross-compiling sense)

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

#53

Post by kelnos »

kazinator wrote: post #49
stephen_g wrote: post #22

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 Raspber…

She's not building on the B+, though. Quote: I started trying to take binaries from my "build host" (a much faster Pi 4B) to run them on this original beast. It throws an illegal instruction. This is like building something with the latest MSVC on Windows 11 and trying to run the .EXE on an old PC running Windows XP. :) I suspect the entire Pi distro she's running on the Pi 4B itself won't run on the B+, since all of…

But at the end, she puts together a new SD card for the B+, boots it, and tries to compile an empty program on the B+ itself. "It can compile something it can't even run", she says.

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

#54

Post by mid-kid »

kazinator wrote: post #49
stephen_g wrote: post #22

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 Raspber…

She's not building on the B+, though. Quote: I started trying to take binaries from my "build host" (a much faster Pi 4B) to run them on this original beast. It throws an illegal instruction. This is like building something with the latest MSVC on Windows 11 and trying to run the .EXE on an old PC running Windows XP. :) I suspect the entire Pi distro she's running on the Pi 4B itself won't run on the B+, since all of…

She was building on the B+ in the later example of the blog.

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

#55

Post by [deleted] »

kazinator wrote: post #49
stephen_g wrote: post #22

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 Raspber…

She's not building on the B+, though. Quote: I started trying to take binaries from my "build host" (a much faster Pi 4B) to run them on this original beast. It throws an illegal instruction. This is like building something with the latest MSVC on Windows 11 and trying to run the .EXE on an old PC running Windows XP. :) I suspect the entire Pi distro she's running on the Pi 4B itself won't run on the B+, since all of…

[deleted]

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

#56

Post by opello »

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?

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

#57

Post by kazinator »

mid-kid wrote: post #54
kazinator wrote: post #49

Earlier quoted context omitted.

She's not building on the B+, though. Quote: I started trying to take binaries from my "build host" (a much faster Pi 4B) to run them on this original beast. It throws an illegal instruction. This is like building something with the latest MSVC on Windows 11 and trying to run the .EXE on an old PC running Windows XP. :) I suspect the entire Pi distro she's running on the Pi 4B itself won't run on the B+, since all of…

She was building on the B+ in the later example of the blog.

Ah I see that now.

The interesting question there is why does the clang binary itself run on the old hardware?

It must be that the distro build uses a different compiler configuration for itself from the configuration imbued into the installed clang.

Maybe it even builds clang twice: once to produce a clang that runs on the machine that builds the distro, which then compiles the packages, including the clang to run on the Pi.

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

#58

Post by adhesive_wombat »

einr wrote: post #37
yjftsjthsd-h wrote: post #30

Earlier quoted context omitted.

> When the Raspberry Pi B+ was released (2014), the ARM core it used was already 11 years old (using the ARM1176 core from 2003). IIRC the original Pi used leftover chips from a TV box, which is the kind of product that IME never ships more compute than they have to, for price reasons.

TV boxes IME usually ship with less compute than they have to [in order to provide reasonable UX] ;)

Anything to satisfy whichever law it is that says "lagginess remains constant".

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

#59

Post by opello »

opello wrote: post #56

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?

I really wish I understood the Debian change management process better. I guess I don't even really know if Raspbian is actually maintained by Debian.

But, when comparing [1] to [2], the rules file has a nice test that says "if DEB_HOST_ARCH is armhf, set the LLVM_HOST_TRIPLE to armv6k..." which seems to confirm a build configuration change.

[1] http://raspbian.raspberrypi.org/raspbian/pool/main/l/llvm-to...

[2] http://raspbian.raspberrypi.org/raspbian/pool/main/l/llvm-to...

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

#60

Post by orra »

opello wrote: post #59
opello wrote: post #56

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?

I really wish I understood the Debian change management process better. I guess I don't even really know if Raspbian is actually maintained by Debian. But, when comparing [1] to [2], the rules file has a nice test that says "if DEB_HOST_ARCH is armhf, set the LLVM_HOST_TRIPLE to armv6k..." which seems to confirm a build configuration change. [1] http://raspbian.raspberrypi.org/raspbian/pool/main/l/llvm-to... [2] http…

To answer your incidental question, Raspian is maintained by Raspberry Pi folks, not Debian.
Post reply on HN