Classic snaps failing on Ubuntu 17.10

snapcraft
41

Any update on this?

To make sure I understand, I think the plan here is to change the process of building a classic snap so that instead of having LDFLAGS set during the build step, something in some later step will patch any ELF binaries in the snap to have a custom interpreter. This interpreter will call the interpreter from the core^Wbase snap with a --list so that any dynamic libraries are resolved from the either the snap being built or the base snap.

This sounds like a good change to me and will let me simplify the go snap’s build plugin a whole bunch. When can I get it? :slight_smile:

1 Like
42

Being worked on now, just a bit complicated due to the current sprint.

1 Like
43

I think this is why the snapcraft snap doesn’t work on trusty as well, LP: #1723208.

44

Any news on this issue?
I’m still having issues with the ubuntu-make snap.
It just returns a segmentation fault.

45

Is there any update on this? I am running Ubuntu 17.10 and would like to install Android Studio, to do this I need to install the latest version of Ubuntu Make which can be installed through snap, however I am getting stuck here:

charlie@thinkpad:~$ snap install ubuntu-make --classic
ubuntu-make master from 'didrocks' installed
charlie@thinkpad:~$ ubuntu-make.umake android
Segmentation fault (core dumped)

If anybody could help me out with this I would greatly appreciate it!

46

snapcraft#1635 was merged last week, although not released yet, which is the fix for bug 1723208.

You can try it by installing snapcraft --edge --classic or, if you’ve already installed it switch to the edge channel with snap refresh snapcraft --edge --classic.

Be sure you’re using the snap if you also have the apt package installed.

$ which snapcraft
/snap/bin/snapcraft
2 Likes
47

6 posts were split to a new topic: Creating a snap for ubuntu-make

48

Hey folks, quick update here on the progress we’ve made.

A couple of short-term fixes have landed that make progress on this issue, but don’t completely fix it:

  • LP: #1723208 has been fixed in master, but that did not end up being due to this issue, but rather a leaking LD_LIBRARY_PATH in the snapcraft snap itself.
  • One of the issues here is that Snapcraft doesn’t exclude libraries from the snap unless the build host is a release that corresponds to a core snap, i.e. currently only Xenial. On releases where this isn’t the case, snapcraft took the step of at least ensuring libc.so.6 didn’t make it into the snap, but that of course ignores everything else in libc, so that measure never worked. PR: #1632 landed in master fixing this issue by making sure every lib in the libc package was excluded.

Another fix in the pipline is PR: #1636 where we get a little smarter about determining the host OS. As soon as that fix lands, combined with the other two, once Snapcraft (a classic snap that we’re using to prove this out) is rebuilt with them we have a snap that runs on Trusty.

That, of course, goes the wrong direction for some of you (older releases rather than newer ones). We’re making progress on that as well, but the problems there take longer to solve (see earlier in this thread). It is a top priority, but the poor soul doing this work just had two sprints and presented at a conference, heh. Expect to hear more soon.

49

@sergiusens How’s the change that patches the interpreter on classic snaps going?

50

Getting there. We want to release 2.34 first as it has become huge and the changes for this require some code changes for which we want to have a solid baseline to come back to. So my estimate is, if adt starts working on our release branch for 2.34 for it to happen 1 week from now.

1 Like
51

@sergiusens Any news about this issue?

52

Using snapcraft on edge and building from 16.04 today has the working bits to produce sound snaps as long as you do not blindly use the desktop-helper as that sets up all the library paths for “called out” runnables to break LD_LIBRARY_PATH for custom libraries in snap

53

@sergiusens Can you elaborate what you mean by “do not blindly use the desktop-helper” please? Does this mean we should not use desktop-helpers at all in classic snaps?

54

It is explained in the linked topic pretty well by @jamesh

But in summary, you can use the part to get the bits, just not the script to launch and that would need crafting on a case by case basis to avoid squatting and breakage (depending if the app launches processes on the host or not).

1 Like
55

I think @sergiusens is actually referring to this topic:

Note that it isn’t as simple as “not using desktop-launch” though. That will prevent LD_LIBRARY_PATH from being altered, but it is likely that many of the libraries desktop apps use will start searching for their plugins from the host system rather than those shipped with the snap.

I don’t have a good answer for this other than:

  1. rebuild GTK+ and all other libraries that have plugins to use a prefix of /snap/myapp/current/ so they’ll have the correct search path without setting an environment variable.

  2. modify the application to sanitise the environment before calling a subprocess. I’m not sure quite how you’d do this other than running something before desktop-launch to capture the pristine environment.

I don’t think there is an easy answer like using patchelf to modify rpaths.

1 Like
56

@sergiusens Hello from 2021 :wink: