5.7.6beta22 build fail on CentOs

[dwcaress]

My initial take at the 5.7.6beta22 release is failing to build on CentOs 7.6 w/ gcc 4.8.5

The autoconf macro I invoke results in the use of -std=gnu++11 compile flags.

It doesn’t like a c++ structure defined in src/utilities/mbprocess.cc , failing at the line including "data(nullptr) {}”. The error message is below. The same code builds fine on MacOs and Ubuntu.

struct mbprocess_grid_struct { mbprocess_grid_struct() : file(""), projectionname(""), projection_mode(0), projection_id(""), nodatavalue(0.0f), nxy(0), n_columns(0), n_rows(0), min(0.0), max(0.0), xmin(0.0), xmax(0.0), ymin(0.0), ymax(0.0), dx(0.0), dy(0.0), data(nullptr) {}

public: mb_path file; mb_path projectionname; int projection_mode; mb_path projection_id; float nodatavalue; int nxy; int n_columns; int n_rows; double min; double max; double xmin; double xmax; double ymin; double ymax; double dx; double dy; float *data; };

/bin/sh ../../libtool --tag=CXX --mode=link g++ -std=gnu++11 -g -O2 -m64 -o mbpreprocess mbpreprocess.o ../../src/mbaux/libmbaux.la ../../src/mbio/libmbio.la -L/usr/local/lib64 -R /usr/local/lib64 -lgmt -lpostscriptlight -lnetcdf -lproj -lm libtool: link: g++ -std=gnu++11 -g -O2 -m64 -o .libs/mbpreprocess mbpreprocess.o ../../src/mbaux/.libs/libmbaux.so -L/usr/local/lib64 -L/usr/lib64 /usr/local/src/MB-System-5.7.6beta22/src/mbio/.libs/libmbio.so -lgdal ../../src/mbio/.libs/libmbio.so /usr/local/src/MB-System-5.7.6beta22/src/bsio/.libs/libmbbsio.so /usr/local/src/MB-System-5.7.6beta22/src/surf/.libs/libmbsapi.so /usr/local/src/MB-System-5.7.6beta22/src/gsf/.libs/libmbgsf.so /usr/local/src/MB-System-5.7.6beta22/src/mbtrn/.libs/libr7kr.so /usr/local/src/MB-System-5.7.6beta22/src/mbtrn/.libs/libmframe.so -lpthread -lgmt -lpostscriptlight -lnetcdf -lproj -lm -Wl,-rpath -Wl,/usr/local/lib64 depbase=echo mbprocess.o | sed 's|[^/]*$|.deps/&|;s|\.o$||';\ g++ -std=gnu++11 -DHAVE_CONFIG_H -I. -I../../src/mbio -I../../src/mbio -I../../src/mbaux -I../../src/gsf -I../../src/mbtrn/r7kr -I../../src/mbtrn/utils -I../../src/mbtrn/mframe/src -I/usr/local/include/gmt -I/usr/include -g -O2 -MT mbprocess.o -MD -MP -MF $depbase.Tpo -c -o mbprocess.o mbprocess.cc &&\ mv -f $depbase.Tpo $depbase.Po mbprocess.cc: In constructor \u2018mbprocess_grid_struct::mbprocess_grid_struct()\u2019: mbprocess.cc:87:19: error: incompatible types in assignment of \u2018const char [1]\u2019 to \u2018mb_path {aka char [1024]}\u2019 data(nullptr) {} ^ mbprocess.cc:87:19: error: incompatible types in assignment of \u2018const char [1]\u2019 to \u2018mb_path {aka char [1024]}\u2019 mbprocess.cc:87:19: error: incompatible types in assignment of \u2018const char [1]\u2019 to \u2018mb_path {aka char [1024]}\u2019 make[3]: [mbprocess.o] Error 1 make[3]: Leaving directory `/usr/local/src/MB-System-5.7.6beta22/src/utilities' make[2]: [all] Error 2 make[2]: Leaving directory /usr/local/src/MB-System-5.7.6beta22/src/utilities' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory/usr/local/src/MB-System-5.7.6beta22/src' make: *** [all-recursive] Error 1 bash-4.2$ gedit src/utilities/mbprocess.cc & [2] 115479

bash-4.2$ cat /etc/centos-release CentOS Linux release 7.6.1810 (Core)

bash-4.2$ gcc --version gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)

[carueda]

Just to comment that 5.7.6beta22 was failing for me in the couple of super quick attempts I recently did as part of resuming work on #807 (which is based on a centos:7 docker hub image); I didn't put much attention on the errors themselves as that was just part of basic preparations. However, the build completed fine today with 5.7.6beta23.

EDIT: in case it helps, the gcc version in the MB-System image:

$ docker run -it --rm mbari/mbsystem:5.7.6beta23 gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)

[dwcaress]

Carlos,

Actually, I went through several attempts at beta23 yesterday before I got to a state that would build on my Mac w/ GMT6 & Proj6, on Ubuntu 16 w/ GMT5 and Proj5, and CentOs 7 w/ GMT5 and Proj4. The beta22 distribution definitely doesn’t work on CentOs 7.

As Kurt has pointed out, we need to augment the Travis CI Ubuntu 16 test build with several other builds, covering at least Ubuntu 16 and 18 and CentOs 7 and 8 with various GMT and Proj versions.

Thanks, Dave

On Jan 12, 2020, at 4:29 PM, Carlos A. Rueda notifications@github.com wrote:

Just to comment that 5.7.6beta22 was failing for me in the couple of super quick attempts I recently did as part of resuming work on #807 (which is based on a centos:7 docker hub image); I didn't put much attention on the errors themselves as that was just part of basic preparations. However, the build completed fine today with 5.7.6beta23.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

---

David W. Caress Principal Engineer Seafloor Mapping Lab

Monterey Bay Aquarium Research Institute 7700 Sandholdt Road Moss Landing, CA 95039

caress@mbari.org http://www.mbari.org/~caress/

Phone: 831-775-1775

[schwehr]

To help with cross referencing: https://github.com/dwcaress/MB-System/commit/5364dd40f28d2d278a0820f2561d438eace96c50

[schwehr]

Oh wow. That's a broken compiler. Is a newer gcc not available as an install on CentOs 7.6? I think if it gets to at least gcc 5, life will be a ton better.

I've not used CentOS in more than a decade, but there has to be a reasonable option.

https://forums.centos.org/viewtopic.php?t=66500

I thought GCC 4.8.1 was good enough, but I guess not:

https://gdal.org/development/rfc/rfc68_cplusplus11.html

[dwcaress]

I've had a CentOs 8 VM built for me, and am unable to make much progress towards installing GMT. The packages available for CentOs8 do not include GDAL: https://bugzilla.redhat.com/show_bug.cgi?id=1741567 It seems that GDAL cannot be built even from source because one or more dependencies aren't available.

No GDAL ==> no GMT ==> no MB-System.

It seems as though it will be easier to require an updated compiler than to move on from CentOs 7.

[schwehr]

https://bugzilla.redhat.com/show_bug.cgi?id=1741567 - Request to package gdal for EPEL 8

[klheadley]

FWIW, if I'm doing it right, 5.7.6beta23 (w/o TRN) builds on CentOS7 x86_64 VM using gcc 4.8.5 However, -std=gnu++11 seems to break the TRN build. Build output and dependency version info attached.

mbsys-5.7.6b23-centos7-build.txt

[schwehr]

@klheadley Why are you using the gnu specific c++11? It's generally better to stick to -std=c++11 A quick look at TerrainNav.cpp shows trouble:

#include <sys/stat.h>
#include <unistd.h>
#include <libgen.h>

#include "TerrainNav.h"
#include "TNavConfig.h"
#include "TerrainNavLog.h"

It should do #include <cmath> and use std::isnan. My feeling that following Include What You Use (IWYU) is the only way to survive C++. Counting on includes to include other things that the code needs makes maintenance really difficult.

And mbtrnav/terrain-nav/structDefs.h

#include "matrixArrayCalcs.h"
#include "myOutput.h"
#include "trn_log.h"

#include "math.h" // <-- use #include <cmath>x
#include <fstream>
#include "string.h" // Don't do this.  Use #include <cstring>

#include <newmatap.h>
#include <newmatio.h>

And don't use using namespace std; . That road leads to insanity.

grep using * | grep 'std;'
matrixArrayCalcs.h:using namespace std;
OctreeTestCode.h:using namespace std;
TerrainMap.cpp:using namespace std;
TerrainNav.h:using namespace std;

[klheadley]

@schwehr - I didn't intentionally choose gnu++11; It built previously, and I imagined that MB-System (configure) sets that flag by default.

Really, I'm just noting (for @dwcaress ) that the MB-System changes appear to break the TRN build and we'll need to fix it at some point, which may be trivial, or may not - I just don't know. If we can keep using trndev branch, we can defer if the rabbit hole turns out to be deep.

And that, on the issue at hand, I can apparently build on CentOS7/gcc4.8.5 if that helps.

The TRN code (which is tangential to MB-System) does need updating; it contains many layers of student work. That's a work in progress; your recommendations are good ones, thanks for those. Since the TRN code is being actively developed for operations, changes are subject to various schedule and resource constraints, and require testing. Given the nature of operations, we are pretty deliberate (glacial) when it comes to making changes :o)