<div dir="ltr">Dear Salva,<div><br></div><div>I have tried once again to build subsurface and smtk2ssrf from the sources; once more I did not succeed in completing the build.</div><div><br></div><div>I tried with Fedora 24, after having installed the hitherto missing package libgit2-devel ; the reeason for the failure</div><div>can be found in file build.log :</div><div><br></div><div><div>In file included from /home/ale/src/subsurface/smtk-import/smartrak.c:32:0:</div><div>----</div><div>/home/ale/src/subsurface/./core/dive.h:20:0: warning: "MAX" redefined</div><div> #define MAX(x, y) ({ \</div><div> </div><div>In file included from /usr/lib64/glib-2.0/include/glibconfig.h:9:0,</div><div> from /usr/include/glib-2.0/glib/gtypes.h:32,</div><div> from /usr/include/glib-2.0/glib/galloca.h:32,</div><div> from /usr/include/glib-2.0/glib.h:30,</div><div> from /usr/include/mdbtools.h:33,</div><div> from /home/ale/src/subsurface/smtk-import/smartrak.c:28:</div><div>/usr/include/glib-2.0/glib/gmacros.h:288:0: note: this is the location of the previous definition</div><div> #define MAX(a, b) (((a) > (b)) ? (a) : (b))</div></div><div>----</div><div>----</div><div>"CMakeFiles/smtk2ssrf.dir/build.make:247: recipe for target 'smtk2ssrf' failed make[2]: *** [smtk2ssrf] Error 1"</div><div>----</div><div>BTW I do not understand why the usual MAX(x,y) macro should be redefined ...</div><div><br></div><div>I tried also with Ubuntu xenial; here the reason for the falure seems to be a missing package; I guess a source package ...</div><div><br></div><div>The relevant files with the logs of the build trials can be found at the followin URL:</div><div><a href="https://www.dropbox.com/sh/p10ri3322hrgtih/AACvIEqNFhlzpeVZMSV9NSpra?dl=0">https://www.dropbox.com/sh/p10ri3322hrgtih/AACvIEqNFhlzpeVZMSV9NSpra?dl=0</a><br></div><div><br></div><div>Very best regards.</div><div><br></div><div>Alessandro</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 17, 2017 at 8:52 PM, Salvador Cuñat <span dir="ltr"><<a href="mailto:salvador.cunat@gmail.com" target="_blank">salvador.cunat@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good night Alessandro.<br>
<br>
On Fri, Feb 17, 2017 at 03:04:06PM +0000, Alessandro Volpi wrote:<br>
><br>
> I have observed that smtk2ssrf does not consider the template dive to be a<br>
> true dive (it is actually fake) and does not export it to the .xml file. I<br>
> guess that 1/1/1900 is not a good date; if I have well understood your<br>
> program reads it as 1/1/2000 , exactly one century later !<br>
><br>
I can see it there, in both your .xml files and mine.<br>
It's being readed as 1/1/2000 because libmdb returns localized strings<br>
for date and time. This wasn't a real problem for date, but actually<br>
was for some times representations (e.g. duration of the dive or<br>
surface time) because of that very big country using 12h and AM/PM<br>
instead of 24h time. So the program fix a "neutral" locale to work; I<br>
selected POSIX locale, but this has the drawback that has only two<br>
digits for the year. This way 1900 becomes 00 and 00 becomes 2000. I<br>
really never expected to find dates before 1969.<br>
<br>
> Coming back to the issue of the .AppImage executables I point out that,<br>
> theoretically, a computer program should ALWAYS BEHAVE THE SAME WAY with<br>
> the same input data, unless the program gets entropy from a source like<br>
> /dev/urandom . I mean that a program which is crashing once with a<br>
> <SEGMENTATION FAULT> SHOULD ALWAYS CRASH WITH THE INSTRUCTION POINTER VALUE<br>
> ALWAYS POINTING TO THE SAME INSTRUCTION. Moreover the program should always<br>
> read the SAME stuff ( right or wrong) in all records, including record<br>
> #15. I do not understand why this record seems not to be as good as any<br>
> other...<br>
><br>
The segmentation fault was due to libmdb failing to identify a table<br>
in the .slg database. As I'm unable to reproduce the crash with your<br>
.slg or any other, I think it could be triggered by a bad interaction<br>
between libraries bundled in the appimage and the libraries in the<br>
host machine.<br>
As said above, dive #15 is in the xml files and it's imported as any<br>
other (with the 01/01/2000 issue). At first I didn't see it because I<br>
have the dive list in subsurface set to be date/time ordered, so it<br>
didn't show the first one. Setting the order to dive number shows it<br>
in first place. Subsurface xml format don't have this issues, so you<br>
can simply edit the #15 dive to be 1900 again.<br>
<br>
> Apparently IT IS NOT ... and I cannot imagine how this could happen. I am<br>
> not familiar with AppImage building procedures and I read on your message<br>
> that you are not also completely at ease with that.<br>
><br>
> Btw I have yesterday tried to run a Subsurface AppImage on Fedora 24. The<br>
> program was working in spite of some complains about wrong libraries and<br>
> in spite of some problem probably related to the application fonts. I<br>
> fully agree with you that the AppImage approach is somehow tricky. I guess<br>
> that the question is much more complicated than simply including<br>
> stand-alone instances of some shared libraries in the executable ...<br>
><br>
<br>
It seems to be. But if Subsurface is running quite well and there are<br>
running appimages for such complex programs as Firefox and others, it<br>
shouldn't be that difficult to get this tiny tool to work. In fact,<br>
except glib2.0 and libmdb the rest of libraries are the same that<br>
those bundled in subsurface appimage.<br>
<br>
> As far as the test of subsurface build scripts on Ubuntu xenial, is<br>
> concerned, I must admit that I was not able to carry it out as promised.<br>
> This has been a busy week for me and I was forced to lend my laptop with<br>
> xenial to a friend of mine.<br>
<br>
Don't worry about it, I was just curious.<br>
<br>
Best regards.<br>
<br>
Salva.<br>
</blockquote></div><br></div>