Live data from Hacker News

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

rachelbythebay.com

131–140 of 150 posts

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

#131
post #96

Earlier quoted context omitted.

Even if it were true that is not the problem. Even sucky devs can crank out code that runs reasonably fast. It just depends on whether the company sees it as a required feature.

Making your code run quickly will not help if your software architecture is inefficient or optimized against the customer as so many web applications are these days, for example. There are many commercial web pages that appear and approximately ten seconds later clicking on a button will actually do something. I am not sure why that it considered acceptable, but customer experience doesn't seem to rank very high on t…

Part of making code run quickly is architecting the solution correctly.

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

#132

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.

Phones, not TV's, but that's pretty much the idea. Even better, the ARM core was tacked on as a sort of "dammit, I supposed we'll have to run applications" kinda thing and isn't even necessarily initialised during boot. Raspberry Pi's actually boot on a really fringe processor called a VideoCore. Arguably the GPU bootstraps the CPU, which makes my brain hurt.

Iirc the original pi was a set top box chip, because it still at the time had directfb gpl code available (as every StB used) - I remember it quite distinctly as I laughed how pointless their experiment was (sort of wrong, but actually the rpi has done more for encouraging competition than anything they've produced themselves)

Also broadcom haven't made phones, while they do still have a strong tv/StB market share, but that's declining due to their incessant proprietary attitude

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

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

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

#134
post #126

Earlier quoted context omitted.

And... does it make sense to you... when you're not cross compiling?

The point is that it objectively CAN compile to the right target. The capability is not broken. It however DOESNT due to a configuration bug. Therefore it doesn’t have to make sense because it’s clearly not intentional. your sentence saying “it can’t build” is therefore incorrect. It’s the distinction between the two capitalized words above.

If "clang helloworld.c" doesn't produce a working a.out out of the box, I think it's fair to say builds are broken. Plenty of projects won't build in those circumstances without some assistance.

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

#135
post #126

Earlier quoted context omitted.

The point is that it objectively CAN compile to the right target. The capability is not broken. It however DOESNT due to a configuration bug. Therefore it doesn’t have to make sense because it’s clearly not intentional. your sentence saying “it can’t build” is therefore incorrect. It’s the distinction between the two capitalized words above.

If "clang helloworld.c" doesn't produce a working a.out out of the box, I think it's fair to say builds are broken. Plenty of projects won't build in those circumstances without some assistance.

Again, that’s not the point. I’m not sure how much clearer this can be made:

1. Nobody is saying it’s not a bad situation. Everyone agrees that it’s non ideal.

2. People who are saying that it can’t produce a usable build are wrong, because it absolutely can produce a usable build with the arch flag explicitly provided.

3. People are conflating a bad default with the inability to do something.

It honestly feels like people are substituting their own sentences in and then arguing against a point that isn’t being made.

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

#136
post #77

Earlier quoted context omitted.

Raspberry Pi Zero (W) are still great. There will be millions of them around in use for decades to come. I will probably always have a few in some drawer. Sad to hear that anyone even considers deprecating support for that hardware. Not to mention all other ARMv6 hardware still around. We need some baseline hardware types that just will always be supported, to add some friction to software rot and bloat in general.

Yeah, I can see the benefits. Are you volunteering to be the one that runs exhaustive regression tests on every distro release? The open source community only thrives as much as people are willing to dedicate volunteer time into making it thrive.

I test my own open source code on a RPi Zero when applicable. I can report bugs to other projects if I happen to notice something is missing, but I can't decide what platforms they should support or not. I can hope that as many as possible can see the value in having some standard fixed, low-performance, high-priority, default targets that are "never" deprecated. But the only thing that would scale is that every project find their own volunteers to make it happen.

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

#137
post #77

Earlier quoted context omitted.

Raspberry Pi Zero (W) are still great. There will be millions of them around in use for decades to come. I will probably always have a few in some drawer. Sad to hear that anyone even considers deprecating support for that hardware. Not to mention all other ARMv6 hardware still around. We need some baseline hardware types that just will always be supported, to add some friction to software rot and bloat in general.

> Sad to hear that anyone even considers deprecating support for that hardware. I don’t think anybody has. This appears to have been entirely an accidental regression.

This was a comment in the thread on distros deprecating ARMv6 support, not the clang issue.

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

#138
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 remov…

> This has nothing to do with the distro; it looks like an upstream LLVM bug.

Wrong: https://news.ycombinator.com/item?id=38505879

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

#139
post #16

Earlier quoted context omitted.

I think RPi has struck a reasonable balance where the mainstream Linux community doesn't really support ancient ARMv6 so RPI themselves maintains forked software (e.g. Raspbian). This way the cost of legacy is borne by those who benefit from it, not everyone.

Raspbian existed well before ARMv6 support dropped off. It's been their main distro from the outset, but mainstream distros with ARM builds only removed support for ARMv6 in the last 1-3 years (depending on distro).

Pretty sure Debian's armhf images have always required ARMv7 or at least for much longer than 3 years. There are also armel images but those don't use hardware floats which makes them much less performant than what the original Pi is capable of. Pretty sure that that mismatch is why raspian exists in the first place.

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

#140
post #13

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…

Yeah, this is not the behavior people expect.

I would expect a arm64 machine to not build a arm32 compatible binary by default, it's the same as running clang on a x86-64 host and expecting it to produce 386 compatible binaries without a -march=i386 somewhere.

The weird clang install on a fresh B+ install is more puzzling, unless there's some user error somewhere.

Post reply on HN