Abstractly, our Guix builds do not treat native-builds and cross-builds
differently. We always build 2 toolchains:

1. A native toolchain (in depends terms: build) (namely, the
   `gcc-toolchain` package, with the command line name being simply
   `gcc`), and
2. A cross toolchain (in depends terms: host) (namely, packages returned
   by the `make-cross-toolchain` procedure in `manifest.scm`, with the
   command line name being something like `x86_64-pc-linux-gnu-gcc`)

This means that even if we are technically not cross
compiling (`build==host`), we do not coalesce or reuse the toolchains in
any way. This is necessary because our release binaries (produced by the
cross toolchain) are built to:

1. Have a dependency on a minimal number of shared libraries
2. Expect the dynamic linker/loader `ld-linux.so(8)` to be somewhere
   like `/lib{,64}/ld*`

This is not the case for binaries produced by Guix's native
`gcc-toolchain` package. They are built to work best in Guix containers,
where the binaries reach for libraries and `ld-linux.so(8)` in
`/gnu/store` and have dependencies recorded as RUNPATHs in their dynamic
section (since paths are deterministic).

In other words, Guix's native `gcc-toolchain` package can be thought of
as a different platform triple: `x86_64-guix-linux-gnu` (PLEASE don't
actually use this triple this is not standard just a way to think about
it).

We can therefore think of performing a Guix build on `x86_64` for
`x86_64` as a cross-compilation with build=`x86_64-guix-linux-gnu` and
host=`x86_64-pc-linux-gnu` since even when the architecture and OS
matches, binaries built with the native toolchain will not run on normal
distros, and binaries built with the cross toolchain will not run in
Guix environments.

---

With this context in mind, we can now discuss our particular issue.

Prior to canonicalizing `$HOST` (this PR), autoconf's barely-working
cross compilation detection (which is marked `# FIXME: To remove some
day.`) set `cross_compiling=yes` if `$host` is not the exact same string
as `$build`:
http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=blob;f=lib/autoconf/general.m4;h=053130b3d0ba7af8b9177da6ff850d8c20ac6cbe;hb=HEAD#l972.
Which actually worked in our favor since we were not canonicalizing
`host` and specifying `build=x86_64-pc-linux-gnu` and
`host=x86_64-linux-gnu`, and the missing `-pc-` made autoconf assume
that it was a cross-compilation.

After canonicalizing `$HOST` autoconf instead sees that `$build==$host`
and sets `cross_compiling=no`, which leads to later configure tests to
compile `conftest` binaries using `CC` (namely, our cross-toolchain
`x86_64-pc-linux-gnu-gcc`) and attempt to run them inside the Guix
container. This leads to the problems fanquake identified here:
bitcoin#21671 (comment)

The solution is to be explicit and supply `cross_compiling=yes` to
`./configure`, which is us saying: "yes i'm on the same architecture,
OS, and userspace as the target, but there are important differences in
what we want in our dynamic sections which lead to binaries not being
able to find the right libraries to load if they were copied to the
other environment so just assume that I'm cross compiling and don't try
to be smart"

Abstractly, our Guix builds do not treat native-builds and cross-builds
differently. We always build 2 toolchains:

1. A native toolchain (in depends terms: build) (namely, the
   `gcc-toolchain` package, with the command line name being simply
   `gcc`), and
2. A cross toolchain (in depends terms: host) (namely, packages returned
   by the `make-cross-toolchain` procedure in `manifest.scm`, with the
   command line name being something like `x86_64-pc-linux-gnu-gcc`)

This means that even if we are technically not cross
compiling (`build==host`), we do not coalesce or reuse the toolchains in
any way. This is necessary because our release binaries (produced by the
cross toolchain) are built to:

1. Have a dependency on a minimal number of shared libraries
2. Expect the dynamic linker/loader `ld-linux.so(8)` to be somewhere
   like `/lib{,64}/ld*`

This is not the case for binaries produced by Guix's native
`gcc-toolchain` package. They are built to work best in Guix containers,
where the binaries reach for libraries and `ld-linux.so(8)` in
`/gnu/store` and have dependencies recorded as RUNPATHs in their dynamic
section (since paths are deterministic).

In other words, Guix's native `gcc-toolchain` package can be thought of
as a different platform triple: `x86_64-guix-linux-gnu` (PLEASE don't
actually use this triple this is not standard just a way to think about
it).

We can therefore think of performing a Guix build on `x86_64` for
`x86_64` as a cross-compilation with build=`x86_64-guix-linux-gnu` and
host=`x86_64-pc-linux-gnu` since even when the architecture and OS
matches, binaries built with the native toolchain will not run on normal
distros, and binaries built with the cross toolchain will not run in
Guix environments.

---

With this context in mind, we can now discuss our particular issue.

Prior to canonicalizing `$HOST` (this PR), autoconf's barely-working
cross compilation detection (which is marked `# FIXME: To remove some
day.`) set `cross_compiling=yes` if `$host` is not the exact same string
as `$build`:
http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=blob;f=lib/autoconf/general.m4;h=053130b3d0ba7af8b9177da6ff850d8c20ac6cbe;hb=HEAD#l972.
Which actually worked in our favor since we were not canonicalizing
`host` and specifying `build=x86_64-pc-linux-gnu` and
`host=x86_64-linux-gnu`, and the missing `-pc-` made autoconf assume
that it was a cross-compilation.

After canonicalizing `$HOST` autoconf instead sees that `$build==$host`
and sets `cross_compiling=no`, which leads to later configure tests to
compile `conftest` binaries using `CC` (namely, our cross-toolchain
`x86_64-pc-linux-gnu-gcc`) and attempt to run them inside the Guix
container. This leads to the problems fanquake identified here:
bitcoin#21671 (comment)

The solution is to be explicit and supply `cross_compiling=yes` to
`./configure`, which is us saying: "yes i'm on the same architecture,
OS, and userspace as the target, but there are important differences in
what we want in our dynamic sections which lead to binaries not being
able to find the right libraries to load if they were copied to the
other environment so just assume that I'm cross compiling and don't try
to be smart"