smtk2ssrf_test.AppImage: further testing

Salvador Cuñat salvador.cunat at gmail.com
Thu Feb 23 15:01:14 PST 2017


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


More information about the subsurface mailing list