Emulating the target architecture's SDK can be much easier and simpler to setup and avoid mistakes. You do not need to make any changes or configuration to make it compile.
For exmaple, that is generally the way you cross compile Flatpaks in cli or ide. In, for example, GNOME Builder you can just select the device you want to build for, like your smartphone, and it uses QEMU to emulate the entire SDK in the target architecture, you can also seemlessly run the Flatpak on your host through QEMU user mode emulation too.
It doesn't need (unless it does in some cases), but entire build process needs to be aware of what needs to be native and what doesn't. Mainly a lot of issue would come from linker. Yes, it's not part of the compilation technically, but aside from hellworld.c everything you build would probably require linker at one point or another.
Then there are some gcc quirks:
- for gcc compilation target is defined when gcc is compiled, so only way to cross-compile with gcc that I know of is emulation of target arch and runing gcc for target arch
However, we're talking about docker containers here, emulation would be the default way and path of least resistance.
Again, I will reiterate: every cross-compilation strategy falls into one of these two buckets. In some cases what I've describe in #1 is possible (WASM, java bytecode or really (almost) anything that targets a VM), in some cases it isn't and then you gotta go with #2 (docker, gcc)
- use native toolchain to produce artifacts for a different architecture
- use emulation to run different arch toolchain to produce different arch artifacts
First one is fast, second one is slow. In docker only second variant is possible.