4 ms·

> mips64 .. must be some kind of legacy hw that's getting current software updates Hundreds of thousands of linux-based smartnic cards, actually. Fun stuff.

> mips64 .. must be some kind of legacy hw that's getting current software updates Hundreds of thousands of linux-based smartnic cards, actually. Fun stuff. Those particular ones were EOLd and have been replaced with ARM but the MIPS based ones will live on in the datacenters until they die, I'm sure. > Like previous you, I have to admit I'm skeptical but would be happy to be wrong Seriously, you are going to be delighted to be wrong. On your linux machine, go write a go program and write "GOOS=darwin GOARCH=arm64 go build ..." and you will have yourself an ARM mac binary. Or for going the other way, use GOOS=linux GOARCH=amd64. It really is that simple.

ncruces 2y ago
It gets even more amazing than that. Look at this bit from my GitHub Actions: https://github.com/ncruces/go-sqlite3/blob/fefee692dbfad39f6365f35f58888cc7cddb8b39/.github/workflows/test.yml#L143-L164 https://github.com/ncruces/go-sqlite3/blob/fefee692dbfad39f6... I install QEMU (I have the same setup locally), then it's one line each to run unit tests for: Linux 386, arm64, riscv64, ppc64le and s390x. With QEMU installed, all you have to do is: GOARCH=bla go test ./...
- cryptofistMonk 2y ago
  Wait is go test automatically running it under QEMU or what's going on here?
  - cryptofistMonk 2y ago
    Ah I found this https://ctrl-c.us/posts/test-goarch https://ctrl-c.us/posts/test-goarch I guess it's qemu-user-binfmt registering the alternate bin formats to automatically run under QEMU, that's pretty neat
    - ncruces 2y ago
      Yep. The Go build system runs under your current architecture, cross-compiling tests to your target architecture. Then, the Go test runner also runs under your current architecture, orchestrating running your cross compiled test binaries. Since you registered to run cross-compiled binaries under QEMU, those test binaries magically run through QEMU. The Go test runner collects test results, and reports back to you. The first run might be slowish, as the Go compiler needs to cross compile the standard library and all your dependencies to your target platform. But once that's done and cached, and if your tests are fast, the edit-test cycle becomes pretty quick.

ncruces 2y ago

It gets even more amazing than that. Look at this bit from my GitHub Actions: https://github.com/ncruces/go-sqlite3/blob/fefee692dbfad39f6365f35f58888cc7cddb8b39/.github/workflows/test.yml#L143-L164 https://github.com/ncruces/go-sqlite3/blob/fefee692dbfad39f6... I install QEMU (I have the same setup locally), then it's one line each to run unit tests for: Linux 386, arm64, riscv64, ppc64le and s390x. With QEMU installed, all you have to do is: GOARCH=bla go test ./...

cryptofistMonk 2y ago
Wait is go test automatically running it under QEMU or what's going on here?
- cryptofistMonk 2y ago
  Ah I found this https://ctrl-c.us/posts/test-goarch https://ctrl-c.us/posts/test-goarch I guess it's qemu-user-binfmt registering the alternate bin formats to automatically run under QEMU, that's pretty neat
  - ncruces 2y ago
    Yep. The Go build system runs under your current architecture, cross-compiling tests to your target architecture. Then, the Go test runner also runs under your current architecture, orchestrating running your cross compiled test binaries. Since you registered to run cross-compiled binaries under QEMU, those test binaries magically run through QEMU. The Go test runner collects test results, and reports back to you. The first run might be slowish, as the Go compiler needs to cross compile the standard library and all your dependencies to your target platform. But once that's done and cached, and if your tests are fast, the edit-test cycle becomes pretty quick.