It's not explicitly stated but in her reproduction she is actually running it on the pi, and compilers very much do normally compile for the arch that they are running on by default.
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.
It’s explicitly stated: “I figured, okay, maybe it's doing some optimization because it was built on the 4B. So, I went and did a build on the B+ natively. It also broke.”
So she was originally compiling on a newer RPi, but immediately switched to compiling on the same one that couldn’t run it. And I believe the actual system images for RPi are built to support all models (there aren’t separate downloads for different models unless you want 64-bit) so it’s not crazy to think that everything would work building on a newer model.
This is just a packaging defect, Clang/LLVM isn’t being configured correctly by RPiOS (Raspbian).
> It's not explicitly stated but in her reproduction she is actually running it on the pi
This is what the post says:
>> This used to work in the old version (bullseye). It now breaks in the current one (bookworm). I figured, okay, maybe it's doing some optimization because it was built on the 4B. So, I went and did a build on the B+ natively. It also broke.
If that's not an explicit statement that she's compiling on the target platform, what is?
It sounds like clang running on the RPi 1 generates code that doesn't run. Usually compilers default to targeting whatever ISA it's running on but that doesn't seem to be the case here.
Usually compilers default to the ISA they were built on. In the case of Clang this is controlled by LLVM_DEFAULT_TARGET_TRIPLE cmake option - maybe a weird mix of options occurred where Clang for armv6 was built on armv7 but the default triple was not adjusted correctly.
Current docs about this option:
> LLVM target to use for code generation when no target is explicitly specified. It defaults to “host”, meaning that it shall pick the architecture of the machine where LLVM is being built. If you are building a cross-compiler, set it to the target triple of your desired architecture.
Yes this could very well be a packaging/build error of clang, rather than a code bug. It's quite usual to cross compile for pi1 because it's so slow to build on it.
> Distro support: By default, Toolbx creates the container using an OCI image called `<ID>-toolbox:<VERSION-ID>`, where <ID> and <VERSION-ID> are taken from the host’s `/usr/lib/os-release`. For example, the default image on a Fedora 36 host would be `fedora-toolbox:36`.
> This default can be overridden by the `--image` option in `toolbox create`, but operating system distributors should provide an adequately configured default image to ensure a smooth user experience.
The compiler arch flags might should be correctly specified in a "toolbox" container used for cross-compilation, too.
There are default gcc and/or clang compiler flags in distros' default build tools; e.g. `make` specifies additional default compiler flags (that e.g. cmake, ninja, gn, or bazel/buck/pants may not also specify for you).
I expect a compile to succeed correctly for any architecture listed in `--print-targets` when I compile a barebones .c/.cpp file on one of those architectures.
