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

111–120 of 150 posts

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

#111

Post by jchw »

cbmuser wrote: post #108

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 (t…

What's weird is that the Clang binary is clearly compiled for an instruction set that is compatible with the Pi B+, but it doesn't target an instruction set that is compatible with the Pi B+. This is genuinely weird, since that's not meant to be a cross-compiler; in theory, the host and the target should be the same.

Presumably the image is Raspbian. I don't see a reason why not to assume that.

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

#112

Post by guipsp »

jchw wrote: post #111
cbmuser wrote: post #108

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 (t…

What's weird is that the Clang binary is clearly compiled for an instruction set that is compatible with the Pi B+, but it doesn't target an instruction set that is compatible with the Pi B+. This is genuinely weird, since that's not meant to be a cross-compiler; in theory, the host and the target should be the same. Presumably the image is Raspbian. I don't see a reason why not to assume that.

One key thing is missing from your comment (which explains the 'weirdness') - clang, and other llvm-family tools are cross-compatible by default. There is no separate cross compilation binary. This is just a configuration bug.

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

#113

Post by dagmx »

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 can, it just doesn’t by default. Which is what the person you’re replying to is saying.

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

#114

Post by devmor »

rbanffy wrote: post #98
swiftcoder wrote: post #65

Earlier quoted context omitted.

This sort of thing is not uncommon in the embedded space. Lots of devices basically built on a DSP with a tiny arm core tacked on the handle application logic

> Lots of devices basically built on a DSP There were many X terminals running off nothing but a Texas 34010, which was a very DSP-like CPU that ended up in a lot of high-end graphics acceleration boards for PCs and Macs (and Unix workstations). The fact it could boot up an X server is quite extraordinary. I wonder what the VideoCore looks like to the programmer.

Sidebar but it’s very annoying how it now takes me a moment to think if people are talking about a social media website or an open source graphical server when I see “X” being discussed in a tech context.

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

#115

Post by jchw »

guipsp wrote: post #112
jchw wrote: post #111

Earlier quoted context omitted.

What's weird is that the Clang binary is clearly compiled for an instruction set that is compatible with the Pi B+, but it doesn't target an instruction set that is compatible with the Pi B+. This is genuinely weird, since that's not meant to be a cross-compiler; in theory, the host and the target should be the same. Presumably the image is Raspbian. I don't see a reason why not to assume that.

One key thing is missing from your comment (which explains the 'weirdness') - clang, and other llvm-family tools are cross-compatible by default. There is no separate cross compilation binary. This is just a configuration bug.

Yes, that's true, although it doesn't actually explain the weirdness. I compile Clang all the time and there's no obvious reason why you'd get cross-compiled binaries out of Clang if you just compile and install it normally. The bug, configuration or otherwise, is the weirdness.

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

#116

Post by rschu1ze »

The database I work on (ClickHouse) tries hard to stay compatible with really old hardware. The standard ARM binaries require Armv8.2 from 2016 (available in Raspberry Pi 2 >=2) and x86 binaries run on hardware from around 2010 (SSE4.2 + pclmul* instructions for fast CRC). We also build (but don't test using CI) binaries for Armv8.0 and SSE2-only systems. A quick install script downloads and unpacks the right binary for the target host.

I find it generally hard to strike a good balance between backwards compatibility and usage of modern CPU features in newer AArch64 generations (https://en.wikipedia.org/wiki/AArch64). We found that there are surprisingly many institutions on a shoestring budget (universities in emerging countries) or hobbyists that can't afford to upgrade their hardware.

On a technical note, what I found quite cumbersome is that the cpu flags in /proc/cpuinfo don't always correspond with the flags passed as -march= to the compiler, e.g. "lrcpc" vs "rcpc". To make all of this work, one really needs to maintain two sets of flags.

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

#117

Post by kjs3 »

rbanffy wrote: post #98
swiftcoder wrote: post #65

Earlier quoted context omitted.

This sort of thing is not uncommon in the embedded space. Lots of devices basically built on a DSP with a tiny arm core tacked on the handle application logic

> Lots of devices basically built on a DSP There were many X terminals running off nothing but a Texas 34010, which was a very DSP-like CPU that ended up in a lot of high-end graphics acceleration boards for PCs and Macs (and Unix workstations). The fact it could boot up an X server is quite extraordinary. I wonder what the VideoCore looks like to the programmer.

The fact it could boot up an X server is quite extraordinary.

Since it was designed explicitly to serve that purpose, I'm not sure why it's 'extraordinary'.

Disclaimer: I spent time at a 34010 X terminal shop.

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

#118

Post by ajb »

Crosseye_Jack wrote: post #100
ajb wrote: post #68

Earlier quoted context omitted.

Are you sure about that? As I understand it, the other product that chip was used in was a Roku stick. It's true that videocore was intended to be a GPU for phones, though.

I am only going off my memory, so I could be mistaken. But IIRC the OG pi used processors originally designed for phones (at least the one that hit the market, eraly prototypes were based on Atmel micros), The iPhone used a processor originally designed for a set-top box from Samsung which was then underclocked to save on battery. IIRC they realised that the micros were not going to cut it, they went to Broadcom (Whi…

It could be the both things are true, it's common enough for chips to be made to serve two markets to save capital cost

I've come across some (unknown provenance) information that bcm2763, which was advertised as a phone chip on an old version of the broadcom website (via archive. org) was the same die as bcm2835, but with dram hooked up in a different way.

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

#119

Post by treyd »

xnzakg wrote: post #86
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.

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

If it's an LG TV this is literally true. They bought webOS specifically for this purpose. Meanwhile Roku invented a runtime/language (BrightScript) and mandated its use to at least enforce a minimum quality standard and throw away cruft.

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

#120

Post by kevin_thibedeau »

jeffparsons wrote: post #61
einr wrote: post #37

Earlier quoted context omitted.

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

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!

My personal peeve is the original Coke Freestyle machines which are overtaxed WinCE systems meant to run with a lower resolution PDA display. They've never resolved all the gross latency issues with them and even the new Freestyle machines are laggy compared to the older Pepsi spire dispensers which could generate fluid full motion video years earlier.
Post reply on HN