This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Sang-Mi A fix to the problem you encountered with netCDF-Fortran version 4.4.0, contributed by Richard Weed, is now available in the developers' snapshot from GitHub: https://github.com/Unidata/netcdf-fortran or you can wait for the release of version 4.4.1, which will be available soon. --Russ > On 07/17/2014 11:27 AM, Sang-Mi Lee wrote: > > Hi Richard and Russ, > > > > Yes, I did compile netcdf C with --disable-netcdf4 option. Here is the > > config.log from netcdf-C installing. I will see if I can enable netcdf4 > > function. > > > > It is not clear what cause the error with 'sizeof'. Warning/error message > > appears after the 'sizeof' is listed below. Also attached is 'config.log' > > from netcdf-4.3.2 > > > > -------------------------------------------------- > > conftest.c(89): error: expected an expression > > if (sizeof ((_Bool))) > > ^ > > > > > > icc: warning #10237: -lcilkrts linked in dynamically, static library not > > available > > /tmp/icckFwzuj.o: In function `main': > > conftest.c:(.text+0x33): undefined reference to `strlcat' > > configure:15181: $? = 1 > > configure: failed program was: > > | /* confdefs.h */ > > > > ---------------------------------------------------- > > > > > > Thank you very much for your help and please keep me posted. > > > > Sang-Mi Lee, Ph.D. > > Program Supervisor - Air Quality Modeling > > South Coast Air Quality Management District > > Phone: 909-396-3169 > > Fax: 909-396-3252 > > > > > > -----Original Message----- > > From: Unidata netCDF Support [mailto:address@hidden] > > Sent: Thursday, July 17, 2014 7:41 AM > > To: Sang-Mi Lee > > Cc: address@hidden; address@hidden; Sang-Mi Lee > > Subject: [netCDF #YYO-369400]: netcdf-fortran-4.4.0 installation error > > > > Richard, > > > >> I'll have to go back and look at the code but this might be due to > >> where I put the mods for the var_fill routines. I don't remember if > >> there is a #ifdef USE_NETCDF4 or equivalent around the logic in > >> netcdf_overloads.f90. If it is the code should probably be moved out > >> of the #ifdef block (or inserted into one). > >> > >> On another matter, I tried to build the code last night on my Linux > >> system at home using Intel 14.0.1 (aka Composer 2013 SP1) and got a > >> weird configure error in hdf5 (8.11.1) as well as the NetCDF 4.3.2 C > >> and Fortran 4.4. > >> > >> For some reason icc is gagging on the sizeof (off_t) test for all > >> three codes. For hdf5 and C 4.3.2, configure continues and generates > >> the make files. However, Fortran 4.4 configure dies at the sizeof test > >> so no make files are generated. > >> > >> It's either something with icc 14.0.1 or the version of the autoconfig > >> tools I have on my system > > > > The sizeof(off_t) test often fails is just because of a problem linking > > with a shared library, becasue it it sometimes the first test that uses the > > LDFLAGS, LD_LIBRARY_PATH, and LIBS environment variables (if the latter two > > exist) when running an executable involving the shared object linke ld.so > > (on Linux). You can see the real cause of the failure by looking closely > > near the end of config.log at the actual error message before the size_t > > message, which is often something like couldn't find the shared object > > libnetcdf.so or libhdf5.so. > > > > Feel free to send us the config.log, attached to a separate email to > > address@hidden (Sang-Mi Lee may not be interested in that problem). > > > > --Russ > > > >> If its icc there might also be other problems with this version of the > >> Intel compilers. I'll try dropping back to Intel 13.1 when I get a > >> chance. > >> > >> RW > >> > >> On 07/17/2014 07:30 AM, Unidata netCDF Support wrote: > >>> Hi Sang-Mi Lee and Richard, > >>> > >>>> I wonder if this is a result of where netcdf_overloads.f90 gets > >>>> included into netcdf.f90. Sometimes, the order in which things are > >>>> processed by the compiler (particularly when using include files) > >>>> can generate this kind of error. Also, I noticed in a previous post > >>>> on this that the person compiling was using parallel make (make > >>>> -j8). I never compile with parallel make so I'm not sure if this is > >>>> something that might make the Intel compiler gag. > >>> > >>> I think the problem may be caused by trying to build netcdf-fortran > >>> using an installed netCDF-C library that doesn't support netCDF-4. > >>> I just tested this with gfortran on Linux, configuring a netCDF-C > >>> library with --disable-netcdf-4 (equivalent to not setting CPPFLAGS > >>> and LDFLAGS to point to an installed HDF5 > >>> library) and got similar errors from gfortran: > >>> > >>> Making all in fortran > >>> make[2]: Entering directory > >>> `/machine/russ/git/netcdf-fortran/.build-v44-v4-v2/fortran' > >>> gfortran -DHAVE_CONFIG_H -I. -I../../fortran -I.. -I../libsrc > >>> -I/machine/russ/installs/nc432-nc4-v2/include -g -O2 -c -o > >>> module_netcdf_nc_data.o ../../fortran/module_netcdf_nc_data.F90 > >>> gfortran -g -O2 -c -o module_netcdf_nc_interfaces.o > >>> ../../fortran/module_netcdf_nc_interfaces.f90 > >>> gfortran -DHAVE_CONFIG_H -I. -I../../fortran -I.. -I../libsrc > >>> -I/machine/russ/installs/nc432-nc4-v2/include -g -O2 -c -o > >>> module_netcdf_nf_data.o ../../fortran/module_netcdf_nf_data.F90 > >>> gfortran -DHAVE_CONFIG_H -I. -I../../fortran -I.. -I../libsrc > >>> -I/machine/russ/installs/nc432-nc4-v2/include -g -O2 -c -o > >>> module_netcdf_nf_interfaces.o > >>> ../../fortran/module_netcdf_nf_interfaces.F90 > >>> gfortran -g -O2 -c -o module_netcdf_f03.o > >>> ../../fortran/module_netcdf_f03.f90 > >>> gfortran -g -O2 -c -o typeSizes.o ../../fortran/typeSizes.f90 > >>> gfortran -g -O2 -c -o netcdf.o ../../fortran/netcdf.f90 > >>> netcdf_overloads.f90:13.52: > >>> Included at ../../fortran/netcdf.f90:48: > >>> > >>> nf90_def_var_fill_FourByteReal, & > >>> 1 > >>> Error: Procedure 'nf90_def_var_fill_eightbytereal' in generic > >>> interface 'nf90_def_var_fill' at (1) is neither function nor subroutine > >>> netcdf_overloads.f90:22.52: > >>> Included at ../../fortran/netcdf.f90:48: > >>> > >>> nf90_inq_var_fill_FourByteReal, & > >>> 1 > >>> Error: Procedure 'nf90_inq_var_fill_eightbytereal' in generic > >>> interface 'nf90_inq_var_fill' at (1) is neither function nor subroutine > >>> netcdf_text_variables.f90:60.93: > >>> Included at ../../fortran/netcdf.f90:56: > >>> > >>> So netcdf-fortran v4.4.0 *requires* a netCDF-4 C library. I think > >>> this is a change from the previous versions of netcdf-fortran, which > >>> built OK even using just a netCDF-3 C library. There may be many > >>> netcdf-fortran users who still only need the netCDF-3 Fortran API, but > >>> for now a workaround is to require a netCDF-4 C library even in that > >>> case. I'm not sure how difficult it would be to fix this ... > >>> > >>>> On 07/16/2014 03:09 PM, Unidata netCDF Support wrote: > >>>>> Hi Sang-Mi, > >>>>> > >>>>>> I encountered errors while installing netcdf-fortran-4.4.0 using intel > >>>>>> compilers (ifort and icc) on RedHat Linux Os version 5.9. The errors I > >>>>>> have appeared in both './configure' and 'make install'. The first > >>>>>> stage is re-directed in 'config.log' in which it complained as below: > >>>>>> > >>>>>> ----------------------------------------------------------------- > >>>>>> --------------------------------------------------------- > >>>>>> icc: warning #10237: -lcilkrts linked in dynamically, static > >>>>>> library not available > >>>>>> > >>>>>> configure:4978: checking whether we are using the GNU Fortran compiler > >>>>>> configure:4991: ifort -c conftest.F >&5 > >>>>>> conftest.F(3): error #5082: Syntax error, found END-OF-STATEMENT > >>>>>> when expecting one of: ( % [ : . = => choke me ---------------^ > >>>>>> conftest.F(3): error #6218: This statement is positioned incorrectly > >>>>>> and/or has syntax errors. > >>>>>> choke me > >>>>>> ---------------^ > >>>>>> compilation aborted for conftest.F (code 1) > >>>>>> configure:4991: $? = 1 > >>>>>> configure: failed program was: > >>>>>> | program main > >>>>>> | #ifndef __GNUC__ > >>>>>> | choke me > >>>>>> | #endif > >>>>>> | > >>>>>> | end > >>>>>> ----------------------------------------------------------------- > >>>>>> --------------------------------------------------------- > >>>>> > >>>>> The above is not a symptom of a problem when you are using ifort. > >>>>> It is expected when running configure, as part of determining that > >>>>> the Fortran compiler is not gfortran. > >>>>> > >>>>>> The second step, 'make check' yielded the following errors: > >>>>>> > >>>>>> [IRIS8]/pln1/local/netcdf-fortran-4.4.0> make check Making check > >>>>>> in fortran > >>>>>> make[1]: Entering directory `/pln1/local/netcdf-fortran-4.4.0/fortran' > >>>>>> ifort -g -c -o netcdf.o netcdf.f90 > >>>>>> netcdf_overloads.f90(9): error #7950: Procedure name in MODULE > >>>>>> PROCEDURE statement must be the name of accessible module procedure. > >>>>>> [NF90_DEF_VAR_FILL_ONEBYTEINT] > >>>>>> module procedure nf90_def_var_fill_OneByteInt, & > >>>>>> ---------------------^ > >>>>>> netcdf_overloads.f90(10): error #7950: Procedure name in MODULE > >>>>>> PROCEDURE statement must be the name of accessible module procedure. > >>>>>> [NF90_DEF_VAR_FILL_TWOBYTEINT] > >>>>>> nf90_def_var_fill_TwoByteInt, & > >>>>>> ---------------------^ > >>>>>> netcdf_overloads.f90(11): error #7950: Procedure name in MODULE > >>>>>> PROCEDURE statement must be the name of accessible module procedure. > >>>>>> [NF90_DEF_VAR_FILL_FOURBYTEINT] > >>>>>> nf90_def_var_fill_FourByteInt, & ---------------------^ > >>>>> > >>>>> From the config.log, I see the version of ifort is: > >>>>> > >>>>> configure:4958: ifort --version >&5 > >>>>> ifort (IFORT) 14.0.2 20140120 > >>>>> > >>>>> This is a recent enough version that I would expect it would > >>>>> support the overloading that's happening in the > >>>>> netcdf_overloads.f90 statments where it's getting errors. The > >>>>> config.log also shows your ifort supports Fortran 2008 > >>>>> ISO_FORTRAN_ENV additions, but not the TS29113 standard extension. > >>>>> > >>>>> We didn't test this release with ifort at Unidata. We do have > >>>>> access to an Intel Fortran development environment on a remote > >>>>> platform where we may be able to reproduce the problem, but that > >>>>> will take some time. In the meantime, I'm also forwarding this > >>>>> question to the developer, Richard Weed, who tests on Intel > >>>>> Fortran as well as gfortran, in case he has time to diagnose the > >>>>> problem ... > >>>>> > >>>>> Richard, I've made the config.log and make.check.log available > >>>>> here, in case you need them: > >>>>> > >>>>> > >>>>> https://drive.google.com/file/d/0Bzp7-lBkQPZ5a1o3bl9rdVE5Nm8/edit?usp=sharing > >>>>> > >>>>> https://drive.google.com/file/d/0Bzp7-lBkQPZ5ZEt5RkkwTjFtVDA/edit? > >>>>> usp=sharing > >>>>> > >>>>> Thanks for any help you can provide! > >>>>> > >>>>> --Russ > >>>>> > >>>>>> Logs files from the two steps are attached. > >>>>>> Any help will be greatly appreciated. > >>>>>> > >>>>>> Sincerely, > >>>>>> > >>>>>> Sang-Mi Lee, Ph.D. > >>>>>> Program Supervisor - Air Quality Modeling South Coast Air Quality > >>>>>> Management District > >>>>>> Phone: 909-396-3169 > >>>>>> Fax: 909-396-3252 > >>>>> > >>>>> Russ Rew UCAR Unidata Program > >>>>> address@hidden http://www.unidata.ucar.edu > >>>>> > >>>>> > >>>>> > >>>>> Ticket Details > >>>>> =================== > >>>>> Ticket ID: YYO-369400 > >>>>> Department: Support netCDF > >>>>> Priority: Normal > >>>>> Status: Closed > >>>>> > >>>> > >>>> -- > >>>> --- > >>>> ----- > >>>> > >>>> Richard Weed, Ph.D. > >>>> Associate Research Professor > >>>> Center for Advanced Vehicular Systems (CAVS) Mississippi State > >>>> University > >>>> > >>>> email: address@hidden > >>>> Phone: (662) 325-5450 > >>>> > >>>> > >>> Russ Rew UCAR Unidata Program > >>> address@hidden http://www.unidata.ucar.edu > >>> > >>> > >>> > >>> Ticket Details > >>> =================== > >>> Ticket ID: YYO-369400 > >>> Department: Support netCDF > >>> Priority: Normal > >>> Status: Closed > >>> > >> > >> -- > >> --- > >> ----- > >> > >> Richard Weed, Ph.D. > >> Associate Research Professor > >> Center for Advanced Vehicular Systems (CAVS) Mississippi State > >> University > >> > >> email: address@hidden > >> Phone: (662) 325-5450 > >> > >> > > Russ Rew UCAR Unidata Program > > address@hidden http://www.unidata.ucar.edu > > > > > > > > Ticket Details > > =================== > > Ticket ID: YYO-369400 > > Department: Support netCDF > > Priority: Normal > > Status: Closed > > > > -- > --- > ----- > > Richard Weed, Ph.D. > Associate Research Professor > Center for Advanced Vehicular Systems (CAVS) > Mississippi State University > > email: address@hidden > Phone: (662) 325-5450 > > Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: YYO-369400 Department: Support netCDF Priority: High Status: Closed