4 ms·

I always wondered - why do we usually need to build software for a target architecture/system on the same architecture/system? Unless the build includes tests,

by Netcob 2y ago

I always wondered - why do we usually need to build software for a target architecture/system on the same architecture/system? Unless the build includes tests, it doesn't need to be run? I get that Apple has its own BS reasons for that, but Linux?

phinnaeus 2y ago
Generally you will always have some system dependencies that you have to manage at the host level. It’s easier to manage those dependencies in the same way the consumers would, in my experience. Containers make this a ton easier of course but then you’re building in a container and you probably wanna make that container match your target environment, soooo…
bpye 2y ago
At least for Nix you _can_ cross compile, but cross compiled and native compiled derivations are not identical - so if you go the cross compiled route you will end up building everything. Another option is to use Qemu and binfmt_misc - that way you do get the result of "native" compilation, but it's slow.
fer 2y ago
> why do we usually need to build software for a target architecture/system on the same architecture/system? Because that's the path of least resistance in terms of development, at least unless you need to industrially build for many architectures. If the compiler runs on $ARCH, the output runs on $ARCH, I guess there's some exception but it's that, an exception. > Unless the build includes tests Build should indeed include tests, unless you want to ship software that potentially fails in architectures you claim to support. Cross compiling isn't a first class citizen in many languages, and when it is, cross testing usually isn't, but you can have a toolchain that includes qemu (as a vm or as a dynamic binary translator) to cover those cases.
deleted 2y ago
[deleted]
dezgeg 2y ago
Cross compilation is much less tested so it's not uncommon to have hidden bugs in the package's build system that break cross compilation. Or that developers straight up disregard cross compilation if they're e.g. hand-rolling Makefiles.

by Netcob 2y ago

phinnaeus 2y ago

Generally you will always have some system dependencies that you have to manage at the host level. It’s easier to manage those dependencies in the same way the consumers would, in my experience. Containers make this a ton easier of course but then you’re building in a container and you probably wanna make that container match your target environment, soooo…

bpye 2y ago

At least for Nix you _can_ cross compile, but cross compiled and native compiled derivations are not identical - so if you go the cross compiled route you will end up building everything. Another option is to use Qemu and binfmt_misc - that way you do get the result of "native" compilation, but it's slow.

fer 2y ago

> why do we usually need to build software for a target architecture/system on the same architecture/system? Because that's the path of least resistance in terms of development, at least unless you need to industrially build for many architectures. If the compiler runs on $ARCH, the output runs on $ARCH, I guess there's some exception but it's that, an exception. > Unless the build includes tests Build should indeed include tests, unless you want to ship software that potentially fails in architectures you claim to support. Cross compiling isn't a first class citizen in many languages, and when it is, cross testing usually isn't, but you can have a toolchain that includes qemu (as a vm or as a dynamic binary translator) to cover those cases.

deleted 2y ago

[deleted]

dezgeg 2y ago

Cross compilation is much less tested so it's not uncommon to have hidden bugs in the package's build system that break cross compilation. Or that developers straight up disregard cross compilation if they're e.g. hand-rolling Makefiles.