Unable to build MET11.0.0 (on Cray HPC)

[robdarvell]

Although I have successfully built MET11.0.0 on the desktop I have been unable to do so on our Cray HPC. The Beta4 release was OK, but I didn't try the Beta5 release (which would have picked it up earlier).
The error message is:
In file included from pair_data_point.h:20,
from met_stats.h:15,
from compute_ci.h:18,
from compute_ci.cc:23:
../../../src/libcode/vx_seeps/seeps.h:180: error: expected ';' before 'override'
../../../src/libcode/vx_seeps/seeps.h:224: error: expected ';' before 'override'
make[3]: *** [libvx_statistics_a-compute_ci.o] Error 1
make[2]: *** [install-recursive] Error 1
make[1]: *** [install-recursive] Error 1
make: *** [install-recursive] Error 1

From the config.log file I am using for gcc
configure:6211: checking for C++ compiler version
configure:6220: g++ --version >&5
g++ (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973]
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:6231: $? = 0
configure:6220: g++ -v >&5
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.3 --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux)

On the desktop version I am using (for context):
configure:6211: checking for C++ compiler version
configure:6220: g++ --version >&5
g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:6231: $? = 0
configure:6220: g++ -v >&5
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)

I haven't had chance to see if I can correct things as yet.

Rob

[JohnHalleyGotway]

@robdarvell I did some reading about the override keyword. The short and simple answer is, please try removing it from src/libcode/vx_seeps/seeps.h and try compiling on the Cray again.

Change FROM: void clear() override;
Change TO: void clear();

Also, please check to see if any newer compiler versions are already available on the Cray that support the C++11 standard. If so, please try compiling MET-11.0.0 as-is using the newer version.

FYI, the override keyword was added to the C++11 coding standard back in 2011. And it's recommended as a way to clearly state that virtual functions in base classes are being overridden in derived classes. It ensures that virtual function overrides are behaving as intended/expected. Of course, we do lots of that in MET and this is the only instance of actually invoking that override keyword. So our usage is anything but consistent.

So while the fix to the immediate problem is simple, the bigger concern is all the questions it raises.

• What C++ standard can the MET codebase use (pre-C++11, C++14, C++17, C++20)? And how should we define/document that?
• How can we automate testing the compilation of MET on very old compilers (i.e. the Cray) and very new compilers (i.e. latest versions of GNU)? Compilation problems do pop up in both cases.

Let's talk more about this at today's development meeting.

[JohnHalleyGotway]

@robdarvell I wrote up the dtcenter/MET#2380 issue to remove the override keyword, so it'll be included in a future bugfix release. But it seems to me that this small change should not warrant a bugfix release at this time.

[robdarvell]

A quick update. I have removed the override keyword within the seeps.h file and recompiled. It has now moved onto some updates made in the seeps.cc before failing (around the SeepsClimoGrid::SeepsClimoGrid section).

Given the age of the compiler I initially used(!) I agree it probably doesn't warrant a bug fix unless others come back with similar issues.

I am trying to find various g++ compilers to try out still.

[JohnHalleyGotway]

@robdarvell I have these open pull requests (dtcenter/MET#2381 and dtcenter/MET#2382) to remove the override keyword. However, I'd prefer to include in those PR's all changes necessary to compile MET on the MetOffice Cray machine. Can you please advise what changes were/are necessary to compiler MET-11.0.0 there?

[JohnHalleyGotway]

Hi @robdarvell, I've merged those two PR's listed above and recommend that we close out this discussion. During our last telecon, you indicated that you'd found acceptable ways of compiling MET-11.0.0 on the Cray and are not requesting any additional changes be included in the MET-11.0.1 bugfix release.

Any objection to marking this discussion as being answered and locking it to prevent future posts?

[robdarvell]

Hi @JohnHalleyGotway no objection to it being closed. We have a way of compiling MET-11.0.0 which will suffice on our current HPC.