Ticket #393: dependency_table.txt

The attached dependency status table, dependency_table.png, (from D. Offiler) contains references and paths specific to the Met Office system.
dependency_table
Dark green: ROPP link with system; Light green: ROPP link with local
For references in square brackets, see the Notes below.
Notes
0. General:

[0.1] All OS and compilers are 64-bit except for the 32-bit SolarisStudio which is compiled to 64-bit targets (using the -m64 flag with suncc and sunf95).

[0.2] All C code is compiled using the system default GNU/GCC gcc compiler which will have the same version number as the system gfortran Fortran compiler shown in the above table. The exception is that suncc is used with sunf95 builds.

[0.3] In order to check the ROPP build support scripts (the main buildpack, build_* wrappers and configs/*_configure_* mini-scripts) all packages have been built on all platforms (and unless noted, all such builds were successful and marked OK). Only those locally-built dependencies marked OK or U in the above status table are used when linking the ROPP tool executables; otherwise the system-installed (distro) dependencies (marked S or S/OK) are used when available. Note, however, that system libraries will likely be older versions than the latest locally-tested releases indicated in the table.

[0.4] Package object libraries marked U are usable even if the make check stage failed to compile or link a test program or a test failed. In these cases, a manual make install may be necessary to install the package files. The ultimate test of 'usable' is that the ROPP tools can link against it without any errors and generate correct output against reference files when run.

[0.5] Package object libraries marked F are not usable due to a configure or compile error. In some cases, it may be due to a mis-configuration which it might be possible correct with deeper investigation; in others there can be a syntax or similar source code error which might in principle be corrected, but it is out of scope for the ROM SAF to correct errors in 3rd-party packages which perhaps affect only one compiler (or compiler family). At best, we might raise a bug report with the package maintainer if the problem is clearly with the code and not a compiler bug.
1. Packages:

[1.1] ZLIB has no Fortran dependencies and is not called directly by Fortran in any other package, so is built generically with just the C compiler; the Fortran ID is merely used to construct the install target path. On almost all *NIX platforms, the system ZLIB can be used, so it is not necessary for the user to locally build this dependency themselves. On all of the above test platforms, ZLIB was built using the ROPP scripts then the installed headers & library files deleted before test-building HDF5.

[1.2] HDF5 has no Fortran dependencies and is not called directly by Fortran in any other package, so is built generically with just the C compiler; the Fortran ID is merely used to construct the install target path. HDF5 may well already be (or can be) system-installed, so try that first. A local build is has been done on RHEL6 (the version under /usr is too old) and Cray HPC (nothing under /usr) though there are versions installed under non-standard paths (not attempted). In all other cases, HDF5 was test-built then the installed files deleted before building netCDF, linking with the system HDF5. In all cases, the system ZLIB was linked.

[1.3] NetCDF-core, although containing only C code, still needs to built for the target Fortran compiler to ensure interoperability with the netCDF-Fortran interface. Except for RHEL6 and Cray HPC, the system HDF5 was linked.

[1.4] NetCDF-Fortran has to be built specifically by and for each target compiler. Except for the Cygwin/GFortran combo, build netCDF locally unless using only the 'system default' Fortran compiler (often GFortran) if there is one.

[1.5] When running its test suite, the GRIB-API installer needs to download a package of test files if not already present. Since the HPC has no direct Internet access (by security policy), the tarball grib_api_test_data.tar.gz must be downloaded first then copied to the HPC alongside the source tarball; the buildpack script will then unpack the test data files to the GRIB-API source tree before running the tests. This step is optional on platforms with Internet access, but note that a pre-build make clean will delete the test files, necessitating a refetch, so we recommend downloading this tarball to the ROPP build directory alongside the other dependency packages on all platforms.

[1.6] Version 000407 is the latest ECMWF 'BUFRDC' package but this is built differently to the 000387 we have used for several years with ROPP. I plan to develop the ROPP build support system later, but for now the old version works well enough.
2. Compilers:

[2.1] Current default on RHEL6. Probably only the latest version from each vendor will be installed on the upgrade to RHEL7.

[2.2] This is the version currently DMI use for their operational chain, although they are considering using gfortran when updating to the latest Ubuntu LTS (14.04) OS.

[2.3] This compiler has only recently installed on RHEL6, and is not yet officially sanctioned for production use. E.g. the NAME model is known not to build with v16 (details unknown). No problems building ROPP (or GBGP) or dependencies.

[2.4] The NAGWare v6.0 compiler licence check only works under the 'official' programming environment (in this case prg_nagfor-6.0.0_64; invoking the binary directly (e.g. via a soft-link) will fail (though the -V option works). As a dirty work-around, buildpack will set the environment if this compiler option is used, then set it back to the (hard-coded current) default after the package install. This hack can be removed if/when v6.0 (or later) becomes the default nagfor.

[2.5] G95 appears to be no longer under development; the last version build was from January 2013 (Linux) or 2010 (Cygwin). ROPP-GG have agreed to drop support for this compiler entirely, but is included here just to see if it works or not.

[2.6] Using the Oracle SunStudio 12.3 release (Fortran v8.6). The latest, 12.4 (Fortran v8.7) has a problem building some (perfectly good) ROPP code on RHEL6, so we use 12.3 for GBGP too. Note that the Sun compilers can have problems finding files when run on the NAS/bulkservers, but are OK when run on LOCALDATA (or other non-NAS disks or other OS). See also [2.14].

[2.7] The suncc C compiler is used with this Fortran compiler, but as it cannot build shared libraries, only static libraries are built with this combo

[2.8] In order for test programs to run on the same Cray HPC login node as used for the compilation steps, then the command:
   module swap craype-haswell craype-ivybridge
must be run first so that each compiler will build for the local Intel architecture (the default is to cross-compile for run-nodes). As I only use the HPC for portability testing, I've put this command in my (HPC) .profile.

[2.9] When using this compiler outside of the Cray programming environment, the compiler commands and the library search path must be set up:
   ln -s /opt/intel/composerxe/bin/ifort ~/bin/ifort
   ln -s /opt/gcc/default/snos/bin/gcc ~/bin/gcc
and in .profile:
   . /opt/intel/composerxe/bin/compilervars.sh intel64

[2.10] When using this compiler outside of the Cray programming environment, the compiler commands must be set up:
   ln -s /opt/gcc/default/snos/bin/gfortran ~/bin/gfortran
   ln -s /opt/gcc/default/snos/bin/gcc ~/bin/gcc

[2.11] This is the command for the Cray HPC Fortran compiler set with the default programing environment. In all *_configure_ftn_linux mini-scripts, etc, the -ef option is used to consistently force lower-case module names (the default being upper-case)

[2.12] The Cray cc compiler fails to build most C-based packages because most auto-generated package configure scripts add a switch -std=c99 which this compiler rejects as an error and so the configure step fails. The GNU gcc compiler is used instead for all packages \u2013 so the compiler command must be set up:
   ln -s /opt/gcc/default/snos/bin/gcc ~/bin/gcc

[2.13] Version 14, the last fully-functioning free (as in beer) Linux release from Intel. I won't be upgrading!

[2.14] Solaris Stidio 12.4 works fine on OpenSUSE (including all ROPP modules). I have also tried Oracle Developer Studio 12.5 (sunf95 v8.8), but there is a definite compiler bug; in link mode, it should (and claims to) pass run-time libraries to the linker with -rpath whereas ld actually gets -path; being an unknown option, the linker issues error and the build of netCDF (or whatever) halts.
3. Specific compiler\u2013package issues:

[3.1] On RHEL6, netCDF-core tests fails when linked with the system HDF5 libraries:

  nc4file.c: In function 'nc4_open_file':
  nc4file.c:2286: error: 'H5LT_FILE_IMAGE_DONT_COPY' undeclared (first use in this function)
  nc4file.c:2286: error: (Each undeclared identifier is reported only once
  nc4file.c:2286: error: for each function it appears in.)
  nc4file.c:2286: error: 'H5LT_FILE_IMAGE_DONT_RELEASE' undeclared (first use in this function)
    

(for all compilers, but of course only gcc is used for this package). This is because our system-installed HDF5 is too old; netCDF v4.4.x requires as a minimum HDF5 v1.8.9 and ours is 1.8.5-patch1. However, linking with the system HDF5 works on OpenSUSE and Cygwin since both are at a supported version. NetCDF builds OK when HDF5 is also built locally. On RHEL6, there is another set of HDF5 files in /usr/local/sci/lib which are v1.8.11. The HPC also has several versions (the latest being v1.8.11) installed under /opt. Howwever, I haven't tried to explcitly use these versions from non-standard paths. Bottom line: on both MetO RHEL6 & Cray, HDF5 v1.8.9 or later needs to be built locally.

[3.2] One test failed in dt_arith.exe which is related to query functions of compiler conversions. This would appear to be a low-level test not of direct relevance to our application, and a manual make install was sucessful. In any case on Cygwin we actually link netCDF and thence ROPP applications with the system version of HDF5 installed via setup64.exe so this local build fail is somewhat academic.

[3.3] Link fails at test program nf_test with 'undefined reference' to exit_. This is because NAGWare compilers don't have EXIT() and similar non-ISO standard routines linkable without some extra magic incantations (like our nag_interfaces.f90 compiled with ROPP itself) Library may still be usuable if make install is run manually.

[3.4] Unrecognized option -shared' when (presumably) linking to build the final (shared) netCDF-Fortran library. It may be possible to build a static library only with the --disable-shared configure flag (not tried).

[3.5] Link fails in tests of Fortran API with 'undefined references' to nc*_ symbols in libnetcdff.so.
Might be an issue with name-mangling underscores in the core lib.

[3.5] Link fails in tests of Fortran API with several 'undefined references' nc*_ 6 Might be an issue with name-mangling underscores in the core lib (g95 is known to use double undercores where the usual standard is one), but since this compiler is unsupported, I'm not investigating further at this time.

[3.5] Even on LOCALDATA, test nf_test fails on RHEL6 (but OK on OpenSUSE)

[3.7] Link of test program nf_test failed with /usr/lib64/libc.a(strcmp.o) with a message to recompile with -fPIE and relink with -pie which for a core system library is not feasible. Hence the ROPP tools depending on netCDF cannot be built with ftn.

[3.8] When testing, KIND=8 in same_int_long.f90 is not recognised as a valid kind type. Setting command-line option -kind=byte (which makes kind type value in bytes instead of default sequence) doesn't help as this just causes 'inconsistent data type' errors between integers in other parts of the test code. Good code would use the portable SELECT_INT_KIND() instead. Library may still be usuable if make install is run manually.

[3.9] Link step fails 'dynamic symbol' from a system library, suggesting to compile with -fpic or -fpie but this is not feasible on HPC.
Summary

    The Cray HPC cc compiler is unsuitable for building most C-based dependency packages but the GNU/GCC gcc can be substituted sucessfully
    The Cray HPC ftn compiler is unsuitable for building dependency packages due to incompatible Fortran and C object codes (configure step fails)
    The Oracle (Sun) Fortran compiler has some issues on our local RHEL6 and central disk systems. Other platforms such as OpenSUSE running completely on a laptop build OK
    The following sub-set of compilers is recommended for formal ROPP-9 testing with the Test Folder system:
        On RHEL6/7:
            ifort13 (supporting builds at DMI)
            ifort16 (or v15 or latest version)
            nagfor60 (or latest version)
            pgf15 (or latest version)
            gfortran (distro default)
            sunf95 (Solaris Studio 12.3)
        On Cray LE:
            ifort15 (or latest version)
            gfortran (distro default)
    Plus basic manual testing on Cygwin with gfortran and one other independent OS (such as my OpenSUSE, with gfortran and at least one other non-GNU compiler).
    Note that only the latest versions of ifort, nagfor and pgf95 may be available should the Linux estate be upgraded to RHEL7 before any ROPP-9 formal (pre-DRI) testing phase begins around Q3/2016.