smtk2ssrf_test.AppImage: further testing

[Alessandro Volpi]

Dear Salva,

I have tried once again to build subsurface and smtk2ssrf from the sources;
once more I did not succeed in completing the build.

I tried with Fedora 24, after having installed the hitherto missing package
libgit2-devel ; the reeason for the failure
can be found in file build.log :

In file included from /home/ale/src/subsurface/smtk-import/smartrak.c:32:0:
----
/home/ale/src/subsurface/./core/dive.h:20:0: warning: "MAX" redefined
 #define MAX(x, y) ({                \

In file included from /usr/lib64/glib-2.0/include/glibconfig.h:9:0,
                 from /usr/include/glib-2.0/glib/gtypes.h:32,
                 from /usr/include/glib-2.0/glib/galloca.h:32,
                 from /usr/include/glib-2.0/glib.h:30,
                 from /usr/include/mdbtools.h:33,
                 from /home/ale/src/subsurface/smtk-import/smartrak.c:28:
/usr/include/glib-2.0/glib/gmacros.h:288:0: note: this is the location of
the previous definition
 #define MAX(a, b)  (((a) > (b)) ? (a) : (b))
----
----
"CMakeFiles/smtk2ssrf.dir/build.make:247: recipe for target 'smtk2ssrf'
failed make[2]: *** [smtk2ssrf] Error 1"
----
BTW I do not understand why the usual MAX(x,y) macro should be redefined ...

I tried also with Ubuntu xenial; here the reason for the falure seems to be
a missing package; I guess a source package ...

The relevant files with the logs of the build trials can be found at the
followin URL:
https://www.dropbox.com/sh/p10ri3322hrgtih/AACvIEqNFhlzpeVZMSV9NSpra?dl=0

Very best regards.

Alessandro

On Fri, Feb 17, 2017 at 8:52 PM, Salvador Cuñat <salvador.cunat at gmail.com>
wrote:

> Good night Alessandro.
>
> On Fri, Feb 17, 2017 at 03:04:06PM +0000, Alessandro Volpi wrote:
> >
> > I have observed that smtk2ssrf does not consider the template dive to be
> a
> > true dive (it is actually fake) and does not export it to the .xml file.
> I
> > guess that 1/1/1900 is not a good date; if I have well understood your
> > program reads it as 1/1/2000 , exactly one century later !
> >
> I can see it there, in both your .xml files and mine.
> It's being readed as 1/1/2000 because libmdb returns localized strings
> for date and time. This wasn't a real problem for date, but actually
> was for some times representations (e.g. duration of the dive or
> surface time) because of that very big country using 12h and AM/PM
> instead of 24h time. So the program fix a "neutral" locale to work; I
> selected POSIX locale, but this has the drawback that has only two
> digits for the year. This way  1900 becomes 00 and 00 becomes 2000. I
> really never expected to find dates before 1969.
>
> > Coming back to the issue of the .AppImage executables I point out that,
> > theoretically, a computer program should ALWAYS BEHAVE THE SAME WAY with
> > the same input data, unless the program gets entropy from a source like
> > /dev/urandom . I mean that a program which is crashing once with a
> > <SEGMENTATION FAULT> SHOULD ALWAYS CRASH WITH THE INSTRUCTION POINTER
> VALUE
> > ALWAYS POINTING TO THE SAME INSTRUCTION. Moreover the program should
> always
> > read the SAME  stuff ( right or wrong) in all records, including record
> > #15. I do not understand why this record seems not to be as good as any
> > other...
> >
> The segmentation fault was due to libmdb failing to identify a table
> in the .slg database. As I'm unable to reproduce the crash with your
> .slg or any other, I think it could be triggered by a bad interaction
> between libraries bundled in the appimage and the libraries in the
> host machine.
> As said above, dive #15 is in the xml files and it's imported as any
> other (with the 01/01/2000 issue). At first I didn't see it because I
> have the dive list in subsurface set to be date/time ordered, so it
> didn't show the first one. Setting the order to dive number shows it
> in first place. Subsurface xml format don't have this issues, so you
> can simply edit the #15 dive to be 1900 again.
>
> > Apparently IT IS NOT ... and I cannot imagine how this could happen. I am
> > not familiar with AppImage building procedures and I read on your message
> > that you are not also completely at ease with that.
> >
> > Btw I have yesterday tried to run a Subsurface AppImage on Fedora 24. The
> > program was working in spite of some complains about wrong libraries and
> >  in spite of some problem probably related to the application fonts. I
> > fully agree with you that the AppImage approach is somehow tricky. I
> guess
> > that the question is much more complicated than simply including
> > stand-alone instances of some shared libraries  in the executable ...
> >
>
> It seems to be. But if Subsurface is running quite well and there are
> running appimages for such complex programs as Firefox and others, it
> shouldn't be that difficult to get this tiny tool to work. In fact,
> except glib2.0 and libmdb the rest of libraries are the same that
> those bundled in subsurface appimage.
>
> > As far as the test of subsurface build scripts on Ubuntu xenial,  is
> > concerned, I must admit that I was not able to carry it out as promised.
> > This has been a busy week for me and I was forced to lend my laptop with
> > xenial to a friend of mine.
>
> Don't worry about it, I was just curious.
>
> Best regards.
>
> Salva.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170223/ea46d404/attachment.html>