Clang now makes binaries an original Pi B+ can't run
rachelbythebay.com
Clang now makes binaries an original Pi B+ can't run
1–10 of 150 posts
Re: Clang now makes binaries an original Pi B+ can't run
#2Re: Clang now makes binaries an original Pi B+ can't run
#3Title is misleading
Re: Clang now makes binaries an original Pi B+ can't run
#4There'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 whatever they want? ;)
Really, this is just laziness and sloppiness on the Linux distro makers' part. Any amount of testing would catch this. Thanks, Rachel!
Re: Clang now makes binaries an original Pi B+ can't run
#5Re: Clang now makes binaries an original Pi B+ can't run
#6Re: Clang now makes binaries an original Pi B+ can't run
#7It 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.
Re: Clang now makes binaries an original Pi B+ can't run
#8[flagged]
A compiler which compiles for a different arch is called a cross-compiler. Unless you explicitly asked for a cross compile, it is indeed surprising for a compiler to emit a binary that won't run on the same machine.
Re: Clang now makes binaries an original Pi B+ can't run
#9[flagged]
Re: Clang now makes binaries an original Pi B+ can't run
#10Edit: 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 again: I forgot about the comment at the end of the article that clarifies that explicitly passing the target results in a working program. In that case, it sounds like some sort of configuration bug--I would assume (but am not certain) that the default target would be the current processor, at least on Unix. That bug I linked was probably about producing incorrect code even when the target was set correctly which, thankfully, isn't happening today.