classic 32 bit application

[Alistair Grant]

Hi James,

Thanks for your follow-up.

On Tue, Apr 04, 2017 at 06:10:32PM +0800, James Henstridge wrote:
> On 4 April 2017 at 03:25, Alistair Grant <akgrant0710 at gmail.com> wrote:
> > Hi James,
> >
> > On Fri, Mar 31, 2017 at 03:08:39PM +0800, James Henstridge wrote:
> >> On 31 March 2017 at 05:38, Seth Arnold <seth.arnold at canonical.com> wrote:
> >> > On Thu, Mar 30, 2017 at 08:10:26AM +0200, Alistair Grant wrote:
> >> >> I'm trying to package a 32 bit software development environment: Pharo
> >> >> Smalltalk (http://pharo.org).
> >> >>
> >> >> I've got it working OK as a devmode package, but as soon as I switch it
> >> >> to classic confinement it fails to run.
> >> >
> >> > I was under the impression the usual progression is from devmode to
> >> > strict. Are you certain classic is the correct direction for your snap?
> >>
> >> I ran into a similar conundrum for the Python snap I built.  If your
> >> package contains a language runtime and interactive shell, it is
> >> difficult to decide what sort of confinement policy makes sense.  It
> >> is possible to run under strict confinement with few or any interfaces
> >> connected, but depending on what the user wants to do might want a lot
> >> more permission (e.g. ability to access the network, ability to write
> >> to the home directory, etc).
> >>
> >> At present the best option seems to be to package things with strict
> >> confinement but ensure that it will be functional if installed with
> >> --classic.  That gives safety by default, but full functionality on
> >> request.  Of course, this means snapcraft isn't giving any help with
> >> the necessary link flags to get things working reliably on non-Ubuntu
> >> systems.  I guess that's something to try and solve next.
> >>
> >> James.
> >
> > This is a step closer, but is still problematic as the bin directories
> > (/bin, /usr/bin, etc.) are still mapped to the snapcraft package.
> >
> > Looks like I'll have to wait until the 64 bit version of the
> > application is available.
> 
> If there are particular utilities usually found in /bin or /usr/bin
> that aren't part of the "core" snap, you will probably need to include
> them in your own snap.  If you still want help with this, it'd be
> useful to give a link to your in-progress snap or snapcraft project.
> Without that, it is a bit difficult to tell what is causing the
> problem.

OK, thanks for the clarification.

The real problem is that I'm unable to get a 32 bit application working
with classic confinement.

The application runs fine in devmode, but building with classic
confinement and running produces:

$ pharo --version
/snap/pharo/x1/usr/bin/pharo: line 13: /snap/pharo/x1/usr/bin/pharo-vm/pharo: No such file or directory
$ ls -l /snap/pharo/x1/usr/bin/pharo-vm/pharo
-rwxr-xr-x 1 root root 4599008 Apr  4 15:15 /snap/pharo/x1/usr/bin/pharo-vm/pharo
$ snap run --shell pharo
$ ldd /snap/pharo/x1/usr/bin/pharo-vm/pharo
	not a dynamic executable

My guess is that I've either configured it incorrectly, or for some
reason the 32 bit architecture isn't working in classic confinement.

The project is at: https://github.com/akgrant43/pharo-snap
I'm just changing the confinement to classic to reproduce the problems.
(A bit of a disclaimer, this is my first snapcraft project and I'm not
familiar with the pharo build process, so the whole thing is still a
work-in-progress, and needs plenty of tidying up :-)).

Thanks again,
Alistair