Crosscompile Essay

this is a draft, partially taken from https://github.com/janvorli/coreclr/commit/0a03ff8f51b87fc8c93b274aa370fef1d5f91192#commitcomment-28916606

generally speaking, the build system user suggests the intent of crosscompilation by doing one or more of the following:

• set CC, AR, LD, NM, etc environment variables to point to the crosscompiler toolchain, and HOSTCC to point to the native host toolchain in case some intermediary helper tools need to be compiled (think small programs that generate headers with settings and similar things). example: sabotage's cmake cross-compile template.
• set CROSS_COMPILE environment variable to point to the cross toolchain triplet, for example i486-linux-musl-. the build system then uses this variable to set all not-yet-set tools, e.g. CC will be set to $(CROSS_COMPILE)cc. this is typically done in Makefile-only build systems such as the linux kernel or busybox.
• autoconf-based build systems use the same concept of prefixing tools like cc ar and ld with the user-provided cross-compilet triplet, however here it is passed using the --host option to configure. example: ./configure --host=i486-linux-musl.

that said, build systems that poke around in the filesystem to try to figure out what system it's running on, where the include directories are, which libraries are installed, guessing which toolchain the user wants to use in an automated way is an absolute horror for any distribution maintainer. this approach may work for the sporadic non-technical user, but not for anyone who tries to get reproducible results.