More architectures like arm32, riscv etc

[wader]

Current issues are:

• Problem finding hosting providing native ARM32, RISCV etc hosts
• Cross compile is messy
• Emulated docker builds a bit less messy but have issues:
  • Emulation is user-land only so /proc/cpuinfo etc from the host leaks into the container confusing some build systems (ex: aom ARM32 build gets confused about CPU features, I think it looks as cpuinfo)
  • How to verify that successful build actually was built with CPU features we want?
• Emulated build is slow and uses lots of resources
  • Current static-ffmpeg with all features can't be build on github action host. Runs out of memory and would probably also run out of CPU time (6h max jobs time). Biggest memory/CPU user is rust it seems, without that it might work.

Some details and attempts here #204

[wader]

@mathieu-aubin let's move arch discussion here

did you read this -> https://www.docker.com/blog/faster-multi-platform-builds-dockerfile-cross-compilation-guide/

and of so, is it relevant? not much time npw but i figured id input

Yeap docker buildx is one thing i'vet tried and it works similar to how the multi-arch images work, does emulation in user-land. It has the issues i described in above.

this one too -> https://hub.docker.com/r/linuxserver/ffmpeg

Had a quick look, would guess they build on native hosts or on fully emulated hosts for each arch https://github.com/linuxserver/docker-ffmpeg/blob/226ddf020af76b99b71dbe3804cfca1919f83c11/Jenkinsfile#L466

It would be interesting to do a github action that boots up a full emulated host per arch. I did some experiments with this once and building worked fine for arm32 etc. The messy part is probably to make it nice to work from a workflow, maybe ideally it could be an action that kind of is a docker action that transfers the job env and runs docker inside the guest.

But sadly if run on a github action host it will still run into the same resources limits that i mentioned above.