Architectures

It hasn’t been deliberately left off, and adding it is certainly something we should do if it’s considered important enough (it is linked to from the snapcraft yaml reference pages).

I think it probably is important enough, but needs a little work (I can do this).

1 Like

Hi, what’s the recommended way to cross-compile (e.g. Go) from amd64 to all other archs?

Could this work? Also with CI like GH Actions? Would I need any command like option to produce that?

base: core20

architectures:
  - build-on: amd64
    run on: [amd64, armhf, arm64]

What you’ve listed says that a single build on amd64 will produce a snap that can be used on the three architectures amd64, armhf, and arm64. You probably want something more like:

architectures:
  - build-on: amd64
    run on: amd64
  - build-on: amd64
    run on: armhf
  - build-on: amd64
    run on: arm64

The snapcore/action-build@v1 action does not currently do anything with this information in the snapcraft.yaml. But if you are set up to do cross builds, then you could probably drive it with:

    steps:
      ...
      - uses: snapcore/action-build@v1
        with:
         snapcraft-args: --target-arch arm64

You could either repeat the action three times to perform the three builds in series from a single job, or use the matrix feature to create three parallel jobs.

Whoops, sorry for the spurious edit! I accidentally saved while updating this post for changes in core22. I think I reverted my changes.

This page should also link to https://snapcraft.io/docs/snapcraft-advanced-grammar

Examples 1-4 could easily be condensed into a single example.

Hello.

How could I crosscompile in core24? I tried this two ways and none works:

platforms:
  arm64:
  armhf:
    build-on: arm64

Multiple builds match the current platform.

platforms:
  arm:
    build-on: arm64
    build-for: [armhf, arm64]

snapcraft internal error: ValidationError(model='SnapcraftBuildPlanner', errors=[{'loc': ('platforms', 'build-for'), 'msg': 'ensure this value has at most 1 items', 'type': 'value_error.list.max_items', 'ctx': {'limit_value': 1}}])

Your first example is correct:

platforms:
  arm64:
  armhf:
    build-on: arm64

It can pack 2 snaps:

  • a snap that is built on arm64 and is built for arm64
  • a snap that is built on arm64 and is built for armhf

When using a build provider (LXD or Multipass), snapcraft will pack both snaps.

When using --destructive-mode, snapcraft will give you the error:

Multiple builds match the current platform.
Recommended resolution: Check the "--platform" and "--build-for" parameters.

because Snapcraft will only build 1 snap locally (for core24 snaps) and it doesn’t know which of the 2 snaps to build. You need to inform snapcraft which to build with snapcraft pack --destructive-mode --platform arm64.

2 Likes

Not sure why, but the ToC on the published version only shows the level-2 headings, which isn’t helpful:

Thanks for the screenshot and for letting us know. I’ve incremented all the headings, which should fix the problem.

1 Like

Is there any rationale for this change? There’s nothing obviously different about core24 at the snapd level, so is this just a Snapcraft limitation?

We’re shipping an architecture: all snap in the default Ubuntu install, so it seems weird to remove this feature.

2 Likes

It’s a snapcraft limitation - no one on the team was strongly opinionated on migrating this feature into core24 and it requires development work to support in snapcraft due to the craft-application integration and with launchpad for remote builds, so it wasn’t prioritized.

That being said, build-for: all could still be added in the future. Can you give us some use cases where building a separate snap for each architecture doesn’t work (or is inconvenient) and links to the snapcraft.yamls where you are using it?

Here’s an example:

Building for every architecture will work, but is wasteful and requires tracking any changes to the supported architectures.

The snap in question is gtk-common-themes. The snap has no apps/daemons/hooks of its own, instead providing architecture independent theme data to other snaps via its content interface slots. It’s been part of the Ubuntu Desktop seed since 18.04.

This is also the model we suggested for people who wanted to package their own themes for use by snaps (all the other gtk-theme-* and icon-theme-* snaps on the store).

I guess the main reasons I’d prefer an architectures: all snap are:

  1. We only need to build it once rather than 6 times, and avoid running builds on the slower architectures.
  2. We know the exact same data will be provided on all architectures, since they’ll be using the same snap revision.
  3. We don’t have to do anything special if a new architecture is added or an existing one removed. The existing revisions will work on the new architecture.

Basically the same reasons you’d use an architecture independent package anywhere else.

I can understand that architecture independent packages might not make sense for some of the other *craft tools, but it is something that is being actively used for snaps. It’s worrying that it was removed without discussion.

3 Likes

Thanks @alan_g and @jamesh, we created some tasks and have started working on this:

1 Like

build-for: [all] is now supported for core24 snaps in Snapcraft 8.3.1.

8.3.1 also adds support for build-for: [all] for core22 snaps for the remote builder.

3 Likes

build-for: [all] is now supported for core24 snaps in Snapcraft 8.3.1

Sorry cannot find out which architectures are supported for gnome extension in core24.
For core22+gnome it were amd64 arm64 armhf (from full list with amd64 arm64 armhf ppc64el riscv64 s390x) to build on snapcraft resources.

Can you please share which archs can be used with core24+gnome?

Looking at the version/channel dropdown in Install gnome-46-2404-sdk on Linux | Snap Store, the gnome extension for core24 has the same support as core22: amd64, arm64, and armhf.

I think we need to update https://snapcraft.io/docs/gnome-extension to include core24 and the list of supported architectures.

1 Like

I suspect there is a typo in the last sentence of the doc:

- a snap built for armhf can stage amd64 packages.
+ a snap built for armhf can stage arm64 packages.

I don’t think armhf snap can natively stage amd64 packages.

It surely can technically (shouldn’t be a prob to pull in any foreign arch packages, no matter which arch they are for), but the usefulness is a bit questionable :slight_smile: