Those are all absolute paths. I'm confused -- >From my phone
-------- Original Message -------- From: Anton Lundin <[email protected]> Sent: Sat Jan 14 11:33:25 PST 2017 To: Dirk Hohndel <[email protected]> Cc: Subsurface Mailing List <[email protected]> Subject: Re: Appimage chdir'ing so relative paths doesn't work 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 <[email protected]>: > > > > > >> On Jan 8, 2017, at 09:38, Anton Lundin <[email protected]> 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/: ... //Anton -- Anton Lundin +46702-161604
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
