classic 32 bit application

[Alistair Grant]

Hi James,

Thanks for your reply.

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.

Thanks again,
Alistair




On Thu, Mar 30, 2017 at 08:10:26AM +0200, Alistair Grant wrote:
> Hi All,
> 
> 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.
> 
> The error message displayed when attempting to run the executable is "No
> such file or directory"
> 
> Attempting to print the shared object dependencies from within a snap
> shell with ldd results in:
> 
> $ ldd /snap/pharo/x1/usr/bin/pharo-vm/pharo
> not a dynamic executable
> 
> Since the only change is the confinement from devmode to classic and
> I've checked that the executable file does actually exist, and it's the
> same one as in devmode, my current hypothesis is that somehow the 32 bit
> environment isn't working properly in classic mode, probably because it
> isn't configured correctly, and not that there's a problem with the
> executable.
> 
> Are there any known problems with 32-bit applications and classic
> confinement, or anything in particular that needs to be configured for
> it to work properly?