Unable to build for armhf on amd64

I’m trying to build a golang app on my amd64 machine which will then run on rpi3. Unfortunately, even with the config below, it still builds the package as amd64.

name: <app-name>
version: git
base: core18

grade: devel
confinement: devmode

  - build-on: amd64
    run-on: armhf

    source: .
    plugin: go
    go-importpath: <import-path>
    go-channel: 1.12/stable
      - gcc

    command: <app-name>
    plugs: [gpio, i2c]

    command: sudo <app-name> run
    daemon: simple
    restart-condition: always
    plugs: [gpio, i2c]

When I try to run the app on the raspberry pi I get: exec: <app-name>: Exec format error … which is usually a indication that it was built for wrong architecture.

Take a look at my reply here: Cross compile snap on amd64 to arm

Ok that does seem to help. It’s now running on my rpi again; But unlike before, the daemon is now not running.
Could this have something to do with the build-override? Do I need to create the daemon script manually and place it somewhere?

If your app is meant to be a service/daemon, you need to declare it as such in your apps such as with

    command: <app-name>
    plugs: [gpio, i2c]
    daemon: simple

You will notice in my original post that I have both a app and service declared. This was working before I started these latest round of updates where I needed the override-build. For some reason the daemon is not working anymore.

2019-07-16T15:17:56Z my-app.my-app-daemon[2613]: sudo: my-app: command not found
2019-07-16T15:17:56Z systemd[1]: snap.my-app.my-app-daemon.service: Main process exited, code=exited, status=1/FAILURE

Not sure why it says command not found. Because I can manually run it vir command line.

Ah I didn’t see that the code pane was scrollable …

You should not be using sudo in the command, as you will not have permissions to run things with sudo from the snap, however daemons always run as root, so it’s unnecessary.

1 Like

Ok that’s working now. It all worked before with sudo actually. So I’m guessing something changed recently that caused this to fail now. Or maybe it’s cause I was building differently. Never specified a base in the past, so probably legacy builds had sudo support, but not the new ones.

AFAIK, sudo should never have worked from inside a strictly confined snap, but I’m happy to see it works for you now