smtk2ssrf_test.AppImage: further testing

Alessandro Volpi volpial at
Fri Feb 24 02:17:47 PST 2017

Good morning, Salva and Anton.

Next week I will try once again with xenial, after having installed
glib-2.0 . I remember that build operation is aimed to ascertain whether
the behavior of of the present AppImage version of smtk2ssrf is like the
behavior of the corresponding regular application. As already explained in
my previous messages the AppImage produces sometimes different output .xml
files from the same input .slg file.

I am now beginning to suspect  that this surprising behavior might be the
result of some instability in libmdb when the Microsoft data base is being
read.  If this is actually the case also the "regular" application would be
affected by the same instability of the AppImage.

As far as the behavior of the build script on Fedora I am probably missing

I have never used cmake and my competence about it is close to zero. My
limited knowledge about the C preprocessor is that a macro is expanded by
the preprocessor before the compilation process is started. In the object
module the macro simply does not exist; it has been expanded by text
substitution and the resulting C source code has been processed by the

It is therefore normal to have the same macro definition in the header of
different source files or even a different definition in different files (
although I would not recommend to do that ). As far as the linking of the
object modules is concerned this should not be relevant.

I remember of having read that it is also possible to have multiple
definitions of a macro inside a single source file, under certain
conditions, but I never dared to do so and I have never found any reason
for doing so. If I need more than one definition for a macro I think that
the best solution is to use different names for different macros. In any
case the  definition "#define MAX(a, b)  (((a) > (b)) ? (a) : (b))" is
standard and is used in a huge number of C source files; therefore I do not
understand why should cmake complain about it, even if the macro definition
is in the header of more than one source file.

Anton is almost certainly right when he says that the issue is related to
need to extend the cmake script so that it is also able to produce a
subsurface Windows executable ... the problem is that such issue only
affects the Fedora version of cmake, since the Ubuntu version seems not to
be affected.

Best regards.


On Thu, Feb 23, 2017 at 11:01 PM, Salvador Cuñat <salvador.cunat at>

> Good night Alessandro and Anton.
> On Thu, Feb 23, 2017 at 10:59:59PM +0100, Anton Lundin wrote:
> > On 23 February, 2017 - Alessandro Volpi wrote:
> >
> > >
> > > 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"
> > > ----
> That are just warnings, what is really failing is:
> [ 88%] Linking CXX executable smtk2ssrf
> c++: error: missing argument to ‘-L’
> CMakeFiles/smtk2ssrf.dir/build.make:247: recipe for target 'smtk2ssrf'
> failed
> make[2]: *** [smtk2ssrf] Error 1
> CMakeFiles/Makefile2:336: recipe for target
> 'CMakeFiles/smtk2ssrf.dir/all' failed
> I've only seen this on fedora. Never on Debian or centOS.
> It's not smtk2ssrf related.
> Could it be triggered by the cmake version included in fedora ?
> The problem in Xenial is because of glib-2.0 not installed.
> In Debian the package is libglib2.0-dev, in Ubuntu is probably the
> same package name.
> > > BTW I do not understand why the usual MAX(x,y) macro should be
> redefined ...
> >
> > There's no such thing as the usual MAX(x,y) macro.
> >
> > On my laptop I find that exact macro in 8 different header files in
> > /usr/include , from about as many different libraries, so its just a
> > matter of time before this kind of things happens.
> >
> > And another angle of it, those where introduced in 475e058d, because
> > windows doesn't have those macros.
> >
> > I'd suggest we throw a #undef before those macros in core/dive.h to get
> > rid of this sort of nonsens issues, our do as we did before 475e058d,
> > and use the ones from sys/param.h on non windows platforms, and ifdef
> > those macros to windows.
> >
> I don't think this is really needed, the warnings only appear because
> of glib-2.0 which is only needed in smtk-import, whose building is
> dissabled by default and has seen little use or even testing until now
> (thanks Alessandro for all your testing here).
> Regards.
> Salva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the subsurface mailing list