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

81–90 of 150 posts

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

#81

Post by aragilar »

opello wrote: post #73
orra wrote: post #70

Earlier quoted context omitted.

Yeah, Raspbian doesn't seem to be developed as a community project. There's no package tracker[1] like Debian or Ubuntu. I suppose they don't tend to diverge much, in practice. Anyway, I suppose this all means Raspberry Pi OS/Raspbian are able to patch this, without requiring it to first be fixed in Debian or Clang. [1] https://raspberrypi.stackexchange.com/questions/1179/does-ra...

Interesting. Uncovering this slight difference really makes me long for something like the Debian GitLab instance (or really any kind of public change tracking) to document a bug or suggest a change. Agreed, sure looks like it's Raspbian's build configuration to fix.

You can also use https://raspi.debian.net/, which is preferable on newer Pis due to the use of arm64 (early Pis had a weird arch which sat between armel and armhf, so either you used armel and things were slow(er), or you rebuilt the packages with the extra float support (as Raspbian did)).

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

#82

Post by Shish2k »

zmgsabst wrote: post #36
bee_rider wrote: post #34

Earlier quoted context omitted.

Big distro. These fat-cat volunteer kernel devs are just trying to keep us down by giving us so much free software that we collapse under the weight of it.

Aren’t a lot of kernel devs paid by large corporations? Eg, this article. https://thenewstack.io/contributes-linux-kernel/

Corporate developers are typically paid to solve corporate problems. Sometimes a company will hire a big-name OSS developer and tell them “continue maintaining your project in whatever way you think best”, but that’s by far the exception rather than the norm.

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

#83

Post by bregma »

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…

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

It has been my experience, over the last 6 decades or so, that it almost always boils down to "doing anything except what I want is a waste of time and resources".

When it comes to free software, you do what you do and learn to ignore the "but what about ME!" demands from those who contribute nothing else. Or you move on and put your energy into something else.

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

#84

Post by zozbot234 »

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…

Typically, support for old hardware is added as part of the "experimental" featureset. Meaning that it's expected to break from time to time as the underlying codebase changes, until the folks who care about that support come around and fix the breakage. If that maintenance stops altogether and the code stays broken, that's when it gets removed.

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

#85

Post by LtWorf »

b112 wrote: post #67
jeffparsons wrote: post #61

Earlier quoted context omitted.

And kiosks, like the McDonald's ordering kiosks. I wouldn't be surprised if they spend more on installation than on building the device itself!

I haven't interacted with these much, but in all such things, eg TVs, others, I get peeved at the thought process. Typical dev time for a new UI from scratch is years. And price drop on parts and their availability will be different down the road. I wonder of people are running all tests, DEV work in KVM or other emulation stacks for DEV, but then not accurately locking clock rate, and limiting RAM during testing. Be…

Most developers suck.

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

#86

Post by xnzakg »

actionfromafar wrote: post #62
adhesive_wombat wrote: post #58

Earlier quoted context omitted.

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

"Huh, this CPU is kind of snappy running native code now. What should we do?" "Let's move application development to Python then, I suppose." "Thanks, that fixed it." Probably what happened in my 55" smart TV dev team.

I would bet that instead of python it's JavaScript and a webapp pretending to be a native application.

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

#87

Post by bitwize »

actionfromafar wrote: post #62
adhesive_wombat wrote: post #58

Earlier quoted context omitted.

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

"Huh, this CPU is kind of snappy running native code now. What should we do?" "Let's move application development to Python then, I suppose." "Thanks, that fixed it." Probably what happened in my 55" smart TV dev team.

Definitely happened on the OLPC.

What's worse, they made a "throbber" effect by string substituting a different color into an SVG, and then reparsing the SVG, for each color it fades through.

That's the kind of coding quality the OLPC project had. That's why it failed, and it probably also factored into why they disabled the view source button.

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

#88

Post by rcarmo »

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…

Most distros and compilers effectively dropped ARMv6 a couple of years back - I had similar trouble building binaries for my old Synology NAS.

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

#89

Post by adhesive_wombat »

bitwize wrote: post #87
actionfromafar wrote: post #62

Earlier quoted context omitted.

"Huh, this CPU is kind of snappy running native code now. What should we do?" "Let's move application development to Python then, I suppose." "Thanks, that fixed it." Probably what happened in my 55" smart TV dev team.

Definitely happened on the OLPC. What's worse, they made a "throbber" effect by string substituting a different color into an SVG, and then reparsing the SVG, for each color it fades through. That's the kind of coding quality the OLPC project had. That's why it failed, and it probably also factored into why they disabled the view source button.

In modern GTK you also have to string-substitute or otherwise construct CSS, pass in as a string and have it reparsed to change element styles. But at least it is native!

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

#90

Post by rowanG077 »

LtWorf wrote: post #85
b112 wrote: post #67

Earlier quoted context omitted.

I haven't interacted with these much, but in all such things, eg TVs, others, I get peeved at the thought process. Typical dev time for a new UI from scratch is years. And price drop on parts and their availability will be different down the road. I wonder of people are running all tests, DEV work in KVM or other emulation stacks for DEV, but then not accurately locking clock rate, and limiting RAM during testing. Be…

Most developers suck.

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.
Post reply on HN