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

101–110 of 150 posts

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

#101

Post by Findecanor »

djmips wrote: post #71
phendrenad2 wrote: post #50

Earlier quoted context omitted.

I guess technically a CPU core within the GPU ASIC block loads code into the main CPU. What a weird design. Feels like the kinda of things that Wozniak would come up with to shave cost from the Apple Macintosh.

AFAIK Woz only really worked on Apple II and Apple /// but his Apple II disk drive controller lived on and was included in the Mac.

Woz also designed Apple Desktop Bus for keyboards and mice. First used on the Apple IIGS, and then on Macs from Macintosh II onwards up until it was replaced by USB.

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

#102

Post by Narishma »

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] ;)

No, they're just bad at software.

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

#103

Post by JonChesterfield »

hulitu wrote: post #75
JonChesterfield wrote: post #69

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

> Picking up information from the environment - a sibling mentions /etc/env.d/gcc - seems fairly likely. Why would CLANG do this ?

If clang didn't try to do the right thing based on the context it finds itself in, people would have to specify a lot more compiler flags to tell it what to do. Target triple, where libc is, where libstdc++ or libc++ is, what linker to use, what flags to pass the linker and so forth. This is much more annoying than `clang foo.c`.

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

#104

Post by shadowgovt »

butlerm wrote: post #96
rowanG077 wrote: post #90

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…

In some cases, it's because the devs are developing locally and never intentionally test with their browser set to simulate latency.

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

#105

Post by nottorp »

fsniper wrote: post #74

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?

Doesn’t seem so sensational when it can’t build binaries for the target machine… on the target machine itself…

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

#106

Post by shadowgovt »

livrem wrote: post #77
woodruffw wrote: post #51

Earlier quoted context omitted.

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…

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.

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

#107

Post by shadowgovt »

jenadine wrote: post #20
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…

The thing with free software is that you are in no position to demand anything. If the maintainer don't feel like supporting your hardware, they don't have to. But the beauty of free software is that you can always do it yourself. (Or pay someone to do it)

If anything, this can be read as, while an inconvenience, an open source success story.

All pieces of the puzzle were open enough that the author could track down the problem and correct it. That, not indefinite support for no-longer-manufactured hardware, is the benefit of open source. It's the thing that enables the other thing.

And thanks to the magic of the internet, blogs, and search engines, now that one person has solved the problem there's a cracking chance that the next person to have the problem will find the solution.

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

#108

Post by cbmuser »

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).

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

#109

Post by cbmuser »

teddyh wrote: post #5

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.

Exactly. The article omits information that is fundamental to being able to fix this problem.

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

#110

Post by cbmuser »

nottorp wrote: post #105
fsniper wrote: post #74

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?

Doesn’t seem so sensational when it can’t build binaries for the target machine… on the target machine itself…

It’s sensational because it’s wrong. LLVM still supports even ARMv5T which is the baseline of Debian’s armel port.
Post reply on HN