Appimage chdir'ing so relative paths doesn't work

[Anton Lundin]

On 14 January, 2017 - Dirk Hohndel wrote:

> On 14 January, 2017 - Dirk Hohndel wrote:
> 
> > On Sat, Jan 14, 2017 at 06:56:35PM +0100, Anton Lundin wrote:
> > > On 13 January, 2017 - Dirk Hohndel wrote:
> > > 
> > > > On Thu, Jan 12, 2017 at 09:49:18PM -0800, Dirk Hohndel wrote:
> > > > > On Tue, Jan 10, 2017 at 07:17:06PM +0100, probono wrote:
> > > > > > 2017-01-08 19:30 GMT+01:00 Dirk Hohndel <dirk at hohndel.org>:
> > > > > > >> On Jan 8, 2017, at 09:38, Anton Lundin <glance at acc.umu.se> wrote:
> > > > > > >> Hi.
> > > > > > >>
> > > > > > >> I was about to test some stuff with the appimage-build and noted:
> > > > > > >>
> > > > > > >> strace -e chdir,open ./Subsurface-4.6-Beta-2-x86_64.AppImage testdata/ostc4.xml |& grep -E 'ostc|chdir'
> > > > > > >> chdir("/tmp/.mount_xyn3Tx")             = 0
> > > > > > >> chdir("usr")                            = 0
> > > > > > >> open("testdata/ostc4.xml", O_RDONLY) = -1 ENOENT (No such file or directory)
> > > > > > >>
> > > > > > >>
> > > > > > >> The chdir'ing might make sense in some case, but in this case it really
> > > > > > >> doesn't.
> > > > > > >
> > > > > > > I think it needs to chdir in order to find its libraries, but I haven't looked
> > > > > > > at this in enough detail.
> > > > > > 
> > > > > > The chdir is required only in cases in which binaries are not
> > > > > > relocatable at runtime (i.e., "/usr" is hardcoded at compile time, for
> > > > > > example for loading resources). If this is not the case (e.g., in the
> > > > > > case of Subsurface), then we should get away without chdir'ing.
> > > > > 
> > > > > I've played around with this for a bit and it's actually quite a bit more
> > > > > complicated than that. All the paths in AppRun.c are currently relative
> > > > > paths - so this needs a bit of work that goes beyond "just don't do that
> > > > > chdir".
> > > > 
> > > > OK, that took a LOT longer than I expected, but over lunch I finally think
> > > > I made it work...
> > > > 
> > > > Anton, can you try the latest AppImage from downloads/daily? That should
> > > > now avoid the chdir and work with relative paths as well.
> > > > 
> > > 
> > > Worked like a charm. I still see quite a bit of relative paths in the
> > > trace prints, and there was quite a bit of them but it worked as
> > > expected.
> > 
> > Not sure where you see them, though. I didn't bother fixing the Python and
> > PERL paths in the AppRun.c that I started from (and as we heard from
> > Simon, I'm clearly on an outdated version), but for LD_LIBRARY_PATH and
> > QT_PLUGIN_PATH we should no longer be using relative paths.
> > 
> > Can you show some examples, just to make sure that it works as expected?
> 
> ...
>   using LD_LIBRARY_PATH=/tmp/.mount_z1TDNY/usr/lib/:/tmp/.mount_z1TDNY/usr/lib/i386-linux-gnu/:/tmp/.mount_z1TDNY/usr/lib/x86_64-linux-gnu/:/tmp/.mount_z1TDNY/usr/lib32/:/tmp/.mount_z1TDNY/usr/lib64/:/tmp/.mount_z1TDNY/lib/:/tmp/.mount_z1TDNY/lib/i386-linux-gnu/:/tmp/.mount_z1TDNY/lib/x86_64-linux-gnu/:/tmp/.mount_z1TDNY/lib32/:/tmp/.mount_z1TDNY/lib64/:
> ...
>   using QT_PLUGIN_PATH=/tmp/.mount_z1TDNY/usr/lib/qt4/plugins/:/tmp/.mount_z1TDNY/usr/lib/i386-linux-gnu/qt4/plugins/:/tmp/.mount_z1TDNY/usr/lib/x86_64-linux-gnu/qt4/plugins/:/tmp/.mount_z1TDNY/usr/lib32/qt4/plugins/:/tmp/.mount_z1TDNY/usr/lib64/qt4/plugins/:/tmp/.mount_z1TDNY/usr/lib/qt5/plugins/:/tmp/.mount_z1TDNY/usr/lib/i386-linux-gnu/qt5/plugins/:/tmp/.mount_z1TDNY/usr/lib/x86_64-linux-gnu/qt5/plugins/:/tmp/.mount_z1TDNY/usr/lib32/qt5/plugins/:/tmp/.mount_z1TDNY/usr/lib64/qt5/plugins/:
> ...
> 

Wasn't that what you asked for? To verify that they where as expected?

The relative paths I see are all in variables that are probably
irellvant, like XDG_DATA_DIRS, PYTHONPATH and so on, which you said you
ignored.


//Anton


-- 
Anton Lundin	+46702-161604