Latest snapcraft fails to build golang classic snap which was working before

snapcraft
1

Hey!

We’re building a classic snap in our CI (with snapcraft cleanbuild) which is simply putting together a golang binary. Since last nights build it now fails with

'/root/build_xxx/xxx' cannot be patched to function properly in a classic confined snap: patchelf --set-interpreter /snap/core/current/lib64/../lib/x86_64-linux-gnu/ld-2.23.so --force-rpath --set-rpath /snap/core/current/lib/x86_64-linux-gnu /tmp/tmphvatyzlr failed with exit code 1.
'patchelf 0.8' may be too old. A newer version of patchelf may be required.
Try adding the `after: [patchelf]` and a `patchelf` part that would filter out files from prime `prime: [-*]` or `build-snaps: [patchelf/latest/edge]` to the failing part in your `snapcraft.yaml` to use a newer patchelf.

(I’ve replaced the actual snap name above as the snap itself is confidential)

This is with snapcraft version 2.39.3

Does this mean all classic snaps now need to be patched?

Also what is the intention of

mypart:
  after: [patchelf]

patchelf:
  prime: [-*]

?

Adding that to all classic snaps feels like something is going in the wrong direction.

Btw. the patchelf snap is published by sergiusens which we should really make canonical if this becomes a required thing by a classic snap build. It also reports an incorrect license of Proprietary whereas patchelf is GPLv3 (check https://github.com/NixOS/patchelf).

Thanks!

regards,
Simon

1 Like
2

Ah I see,

patchelf:
  prime: [-*]

is actually pulling a remote part (as specified on https://wiki.ubuntu.com/snapcraft/parts).

Remote parts are quite hard to spot at times :slight_smile:

This feels still like something is wrong if I have to pull from a personal github tree or a personal published snap as a mandatory build thing for a classic snap.

3

So after adding the above code snippet to the snapcraft.yaml everything builds fine but now crashes at runtime

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7dda949 in ?? () from /snap/core/current/lib64/../lib/x86_64-linux-gnu/ld-2.23.so
(gdb) bt
#0  0x00007ffff7dda949 in ?? () from /snap/core/current/lib64/../lib/x86_64-linux-gnu/ld-2.23.so
#1  0x00007ffff7df0632 in ?? () from /snap/core/current/lib64/../lib/x86_64-linux-gnu/ld-2.23.so
#2  0x00007ffff7dd8c2a in ?? () from /snap/core/current/lib64/../lib/x86_64-linux-gnu/ld-2.23.so
#3  0x00007ffff7dd7c38 in ?? () from /snap/core/current/lib64/../lib/x86_64-linux-gnu/ld-2.23.so
#4  0x0000000000000001 in ?? ()
#5  0x00007fffffffe721 in ?? ()
#6  0x0000000000000000 in ?? ()
4

For reference: The acutal snapcraft.yaml looks like this:

[...]
confinement: classic
grade: devel

[...]

parts:
  go:
    source-tag: go1.9.2
    source-depth: 1

  patchelf:
    prime: [-*]

  abc:
    plugin: go
    source: .
    go-importpath: launchpad.net/xxx/yyy
    after: [go, patchelf]
1 Like
5

The airplane doors are about to close and I will have to power down. But real quick, I will add an option to disable patchelf and leave people be on setting up the correct environment to work on classic. The previous implementation of classic builds in snapcraft only worked for 20% of the population, so we went with this route.

In parallel, I will see if we can get a newer patchelf SRUed, the initial reaction to that was that it wouldn’t be the case. I am not worried about this one as when the buildd’s switch to snaps, you will start using the patchelf embedded in the snapcraft snap.