[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #CSU-834148]: Building methodologies of netCDF4 libraries for multiple compilers and versions


> I am charged with the task of building netCDF-4 libraries (with
> HDF5-parallel capability) for our HPC platforms.  We provide multiple
> compiler suite versions from a set of different "vendors." For example
> here is a paste of the output of compilers we offer to users via the
> modules environment:
> --------------------------------
> /usr/projects/hpcsoft/modulefiles/mustan/compiler
> Compilers:
> gcc/4.7.2                 intel/12.1.5(default)
> pgi/12.10(default)
> gcc/4.6.1                 intel/11.1.072
> intel/13.0.1    pgi/12.6
> gcc/4.7.0(default)    intel/12.1.2                  pgi/10.9
> pgi/9.0-3
> Is it necessary to build a separate netCDF-4 library build for each
> vendor and release above?  Or could I simply have a single library build
> for each compiler vendor  ( This is assuming I am only building the base
> C and Fortran netCDF-4 libraries, I would guess C++ is not so flexible
> between compiler versions ?).

I'm guessing a single C library built with the earliest vesion of gcc
should work fine with programs compiled with later gcc compilers and
frontends, such as gfortran.

I don't know how well programs compiled with later pgi and intel compilers
will work with a library compiled with vanilla gcc, and it may depend on
options used to compile an application program.  For example, if libraries
use gcc -m32, then programs compiled with gcc -m64 (or any other compiler
that uses -m64) won't work, and vice versa, but that problem will be detected
and result in an error message at link time.

Sorry I can't be more helpful, but I think you may just have to test what works
by trying to link an example program using netCDF calls with a candidate library
to see if it returns the expected results.  We have some fairly detailed tests 
all the API functions that are run with "make check".  Maybe you could use one 
more of those to test against a candidate lowest-common-denominator gcc library 

> Any input you could provide would be helpful.  I'm just trying to cut
> down the number of necessary builds.  At this point if I do need to have
> separate builds for each vendor and vendor release, and then MPI library
> (considering OpenMPI 1.4.5 isn't entirely compatible with OpenMPI 1.6.3,
> and then there is MVAPICH.... what I call two different MPI "flavors")
> then the number of independent builds goes like:
> N_vendors * N_vendor_versions * (2 MPI "flavors") * N_mpi_flavor_versions

Wow, that's a lot of builds, and it would probably multiply more depending on
compiler options.  But remember that all the system libraries are probably built
with gcc, and applications compiled with intel and pgi compilers still work when
linked with the system libraries, so you ought to be able to use a single common
netCDF library, or maybe one for 32-bit and one for 64-bit environments.


Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu

Ticket Details
Ticket ID: CSU-834148
Department: Support netCDF
Priority: Normal
Status: Closed

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.