I'm sure the Fedora builds aren't designed for cross compilation (which is far from trivial for most packages not designed for it). Also, man-power is the most precious resource so it would be a waste to spend time trying to cross-compile what could be built natively.

As long as you've got the target toolchain on the host, the code has no idea it's being cross compiled. If you've got the tooling set up it's a lot of setting of envars. It's not trivial but it's also not super difficult. A compiler running native on an architecture doesn't produce any different output than the same compiler doing a cross compilation.

Even if you wanted to run a native RISC-V build process, running it in QEMU on a much more powerful AMD64 system will get you the same results in a fraction of the time. This gets much faster feedback in the CI system.

The older HiFive Unleashed (1.5 GHz single-issue) builds things considerably faster on a per-core basis than qemu-system on current amd64 (or at least did in the Skylake generation). The dual-issue cores in the HiFive Unmatched should be around 50% faster.

amd64 machines do have the advantage that you can get them with 32 or 64 cores and hundreds of GB of RAM -- at a price, especially in power consumption.

The three year old HiFive Unleashed uses around 5W to 6W at the wall when building flat out, considerably less than the maybe 25W a quad core i7 or Ryzen will use, with lower performance running qemu-system.

The new HiFive Unmatched probably has the same or lower power consumption, at 50% higher performance.

Running qemu on a Pi 4 would use about the same power as the RISC-V chip but be waaaaaaay slower.

That's running qemu which is unnecessary for cross compiling. I'm not seeing any advantage to building on native silicon rather than cross compiling on existing machines AMD64 machines. Even with the power usage of the AMD64 chips being higher, the faster compilation speed will likely net less overall energy used for the builds.

I fully understand wanting native silicon to do development on and to work on some architecture specific branch. It's easy to just recompile your working copy locally. The original poster was talking about "build machines". I'm not seeing the utility as "build machines", especially if they have far less power than AMD64 machines.

There are many packages that compile some kind of tools and then run them to produce other things necessary for the build, possibly several layers deep.

In theory you can set up the build system to correctly know which things should be compiled native and which should be cross-compiled. Sometimes you even need native and cross-compiled versions of the same thing.

In practice, this is a capability that few people use and even if everything is set up correctly at some point most people contributing patches do not think about or test maintaining the ability to cross compile and it gets broken.

When you're building hundreds or thousands of packages for a distro such as Debian or Fedora this is a huge problem.

Building natively in a full system emulator or on real hardware is the only way, in practice.

Only for very simple systems. Many are complicated which produce artifacts that are executed to produce other artifacts (which are also compiled). As arbitrary binaries are executed during the build, and the correctness may depend on native execution, this is far from as trivial as you might think. Have you ever compiled Emacs (at least in its 18 version)?

Building under QEMU is obvious, however the native hardware is actually faster.

A Docker image with cross-compilation toolchain?

Other commenters have pointed out how tricky cross compiling can be. Debian has been making a lot of progress here, most thanks to Helmut Grohne it seems. http://crossqa.debian.net/ https://wiki.debian.org/DebianBootstrap (slightly out of date, but still useful)