fan2go Linux ARM64 release is actually X86-64

[happyme531]

Describe the bug
As the title says...

To Reproduce
Steps to reproduce the behavior:

1. Download the latest release fan2go-linux-arm64
2. readelf -h fan2go-linux-arm64

> readelf -h ./fan2go-linux-arm64
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x402450
  Start of program headers:          64 (bytes into file)
  Start of section headers:          20255264 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         14
  Size of section headers:           64 (bytes)
  Number of section headers:         50
  Section header string table index: 49

Expected behavior
fan2go-linux-arm64 is a ARM64 executable.

[markusressel]

Huh, thats interesting. The workflow explicitly sets the target architecture, but maybe this changed at some point?
https://github.com/markusressel/fan2go/blob/master/.github/workflows/go.yml

[markusressel]

Ok so I took a quick look. Seems like the problem is two-fold:

1. The CI isn't passing the environment arguments correctly to the go build argument, which results in the go compiler generating a binary based on the environment, which is linux/amd64 for the CI task.
2. The github.com/md14454/gosensors library uses cgo to create bindings for the lm-sensors project, which cannot be compiled automatically by go without a cross compiler, see: runtime/cgo: cross compile with cgo for target ARM64/linux fails golang/go#28966 (comment)

Fixing the first could be done by explicitly setting the environment variables on the same line as the go build call. However, this will probably not result in a binary beeing created, since there is no cross compiler present within the CI runner - at least I wouldn't expect that to be the case by default. I am not even sure if such a thing exists.

So in conclusion I think the best solution would be actually run the go build command on the proper target hardware, by splitting the current CI action and run it on two separate VMs (one AMD64 and one ARM64) to generate the binaries. Not sure how other projects deal with this, maybe there is a (github action) plugin for this?

[happyme531]

Yeah, there are some Actions plugins for this.
eg. https://github.com/marketplace/actions/arm-runner

GitHub

ARM runner - GitHub Marketplace

Composite action to run commands within a qemu chrooted environment

[markusressel]

I have played around with this one yesterday:
https://github.com/crazy-max/ghaction-xgo

I cannot get it past this error though:
https://github.com/markusressel/fan2go/actions/runs/7770741557/job/21191269166?pr=270#step:4:401

I get the same error when I try to compile it locally on my x64 machine. Since I have no idea how all of this works in detail, I guess using a VM is still the way to go.

GitHub

GitHub - crazy-max/ghaction-xgo: GitHub Action for xgo, a Golang CGO cross compiler

GitHub Action for xgo, a Golang CGO cross compiler - GitHub - crazy-max/ghaction-xgo: GitHub Action for xgo, a Golang CGO cross compiler

GitHub

add cross-compile.yml action · markusressel/fan2go@fddc47b

A simple daemon providing dynamic fan speed control based on temperature sensors. - add cross-compile.yml action · fddc47b