Architectures

doc
3

well, the combination fo build-on and run-on is essentially that …

if you cross build for armhf you’d use “build-on: amd64” and “run-on: armhf” like here:

https://github.com/ogra1/pi-kiosk-gadget/blob/master/snapcraft.yaml#L11

4

@kyrofa it would be very helpful if this doc could have some cross reference to the architecture specific bits in stage-packages: (and/or build-packages) often you use the more exotic build-on/run-on combinations together with arch specific entries in build/stage-packages entries.

1 Like
5

Thanks @ogra I am still a bit confused though. What is the relationship between the root keyword architectures and the command line --target-arch flag?

For example snapcraft --target-arch=armhf and also how about snaps which are “cross platform” (say Bash scripts or interpretted programs) versus programs which need to be compiled separately and linked to platform specific dynamic libraries?

6

Once you have the proper build-on and run-on lines, there is no need for --target-architecture anymore since you defined it in your snapcraft.yaml already.

if you read the first post carefully you will see “run-on: all” … that is for bash scripts and friends :wink:

3 Likes
7

This is work in progress, and documents behavior that does not yet exist in its entirety. The snapcraft CLI gained support for this in v2.42, but it’s not yet fully integrated with build.snapcraft.io.

This is now supported by build.snapcraft.io: that is, builds will be dispatched for the set of architectures requested in snapcraft.yaml, provided that they’re supported by BSI. (In most cases, I expect that the main use case for this will be to disable builds for architectures that you know can’t work, although it will later be a useful building block for build sets.)

This will allow us to enable builds for ppc64el and s390x on BSI (the remaining Ubuntu architectures that we don’t yet support there), but we’ll do that early next week rather than making a significant change like that just before the weekend.

4 Likes
8

This will allow us to enable builds for ppc64el and s390x on BSI (the remaining Ubuntu architectures that we don’t yet support there), but we’ll do that early next week rather than making a significant change like that just before the weekend.

Now done.

2 Likes
9

Is it possible to specify an architecture that we want it not build on? Enumerating all other arches doesn’t seem to be desirable.

For example I know a certain snap won’t build on armhf architecture, is there a way to disable it without enumerating all other architectures in the build-on key?

10

What are all the supported architectures?

11

This should also more explicitly explain What is the proper way to build and support multi-architecture snap in store (year 2018)? and the $SNAP_ARCH_TRIPLET variable.

1 Like
12

The ‘Architectures’ page isn’t visible in the ‘contents’ down the page’s left-hand column. Is that deliberate?

1 Like
13

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
14

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]
15

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.

16

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

17

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

19

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

20

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}}])

21

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
22

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

image
image373×892 36.2 KB

23

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

1 Like