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.
>To: <address@hidden> >From: Matt Brennan <address@hidden> >Subject: problems compiling netcdf for Fortran 90 >Organization: Dept. of Civil & Environmental Engineering, Stanford University >Keywords: 200201191707.g0JH7fx09738, Linux, Intel Fortran compiler Matt, > Thanks for your trouble shooting. I hadn't realized that the f90 code > depended on the f77 code. In the mean time, I've been working on > installing pre-compiled binaries as an alternate way to implement netCDF. > But I've reached a sticking point on this path too. Could you check out > both of the paths I'm working on and pass on your advice about which path > I should pursue and how I might get unstuck? > > Installing the binaries > *********************** > > Before I received your response, I started working on an alternate > solution. I downloaded the netcdf Linux binaries from the webpage > http://www.unidata.ucar.edu/packages/netcdf/binaries.html. I then tested > these binaries using the ftest code included with the netCDF source. > These binaries worked successfully with the ftest program included in the > netCDF source and compiled with my compiler, the Intel Fortran Compiler. > > However, the binaries won't work with the program that I'm ultimately > interested in using. This program, GOTM, is a numerical water column > model written in Fortran 90. However, judging from the GOTM source, this > program still uses the f77 implementation of netCDF, i.e. it does relies > on 'include netcdf.inc' to include the netCDF functions and not the 'use > netcdf' format for f90 modules. > > The errors I get when I try to compile GOTM with the Intel compiler, > including the netCDF library on the compiler path, occur at the linking > stage. The linker can't seem to find the netCDF object files. The errors > (lots of them!) are of the form: > > ncdfout.o(.text+0x3cdf): undefined reference to `nf_put_att_text_' > ncdfout.o(.text+0x3d28): undefined reference to `nf_put_att_real_' > > where ncdfout.o is the object file of GOTM that conducts the netCDF > output. These are similar types of error that I get if I compile ftest > without specifying the path for the netCDF library. But I'm puzzled as > to why the compiler/linker can find the netCDF library in one case but > can't seem to find it in the other. Any suggestions? > > While trying to figure out the problem, I stumbled across a technical > note from Intel discussing linking of object files created by different > compilers. > http://support.intel.com/software/products/compilers/c50/linux/CompilersCompatibility2.pdf. > This document warns against linking object files created by different > compilers. It explicity says that linking with object files created by > g77 won't work. Do you know what compiler was used to create the binaries > on the unidata web site? Do you think I should be concerned about this > inter-compiler issue even if the ftest program worked when compiled with > the Intel compiler? Yes, you've been tripped up by a problem with binary distributions for Fortran libraries: they don't work in general when used with different compilers than were used to build the binary distributions. Our collection of binary distributions (only one per platform) also doesn't include the information needed to determine what compiler and which compiler flags were used in building the binary, necessary to determine how to compile and link an application against the library. (We are discussing how to best provide this information.) The Linux binary distribution you downloaded was built with g77, so won't work with applications compiled with the Intel compiler. And we currently don't have the Intel compiler installed on a Linux platform (though you've pointed out that a free evaluation copy exists). There are some other binary distributions of netCDF for Linux available in the form of .rpm files or Debian dpkg distributions, but these would also only work with a matching Fortran compiler, and I think they are built with g77. So I think you will have to build from source. > Installing from the source code > ******************************* > > I returned to the problem of installing netCDF from the source with more > knowledge: your advice about the f90 installation; the warnings of > inter-compiler linking mentioned above; and the realization that the > modeling code does not require the f90 implementation of netCDF. So I set > the environmental variables to identifiy the Intel compiler as the f77 > compiler and tried to compile the f77 netCDF libraries from the source. > This produced errors in the make stage. It seems that the c preprocessor > doesn't recognize the system. The log files are listed below. > > Do you think I should continue to try and install from the source or will > the binaries be sufficient? ... > `/home/mbrennan/downloads/netcdf/netcdf-3.5.0/src/fortran' > > gcc -c -O -I../libsrc -DNDEBUG fort-attio.c > In file included from ncfortran.h:13, > from fort-attio.c:6: > > cfortran.h:134:3: #error "cfortran.h: Can't find your environment among: > - MIPS cc and f77 2.0. (e.g. Silicon Graphics, DECstations, ...) - IBM > AIX XL C and FORTRAN Compiler/6000 Version 01.01.0000.0000 - VAX VMS CC > 3.1 and FORTRAN 5.4. - Alpha VMS DEC C 1.3 and DEC FORTRAN 6.0. - Alpha > OSF DEC C and DEC Fortran for OSF/1 AXP Version 1.2 - Apollo DomainOS 10.2 > (sys5.3) with f77 10.7 and cc 6.7. - CRAY - NEC SX-4 SUPER-UX - CONVEX - > Sun - PowerStation Fortran with Visual C++ - HP9000s300/s700/s800 Latest > test with: HP-UX A.08.07 A 9000/730 - LynxOS: cc or gcc with f2c. - > VAXUltrix: vcc,cc or gcc with f2c. gcc or cc with f77. - f77 with vcc > works; but missing link magic for f77 I/O. - NO fort. None of gcc, cc or > vcc generate required names. - f2c : Use #define f2cFortran, or cc > -Df2cFortran - NAG f90: Use #define NAGf90Fortran, or cc -DNAGf90Fortran - > Absoft UNIX F77: Use #define AbsoftUNIXFortran or cc -DAbsoftUNIXFortran - > Absoft Pro Fortran: Use #define AbsoftProFortran - Portland Group Fortran: > Use #define pgiFortran" > > make[2]: *** [fort-attio.o] Error 1 The netCDF Fortran interface is implemented by calling C functions. Unfortunately, there is no standard specifying how Fortran calls C functions, and there are many compiler/vendor variations. We depend on the "cfortran.h" solution of Burkhard Burow for implementing the Fortran/C interface: http://www-zeus.desy.de/~burow/cfortran/ The users guide for cfortran.h at http://www-zeus.desy.de/~burow/cfortran/cfortran.html doesn't indicate support for the Intel ifc compiler yet. When a new Fortran compiler such as Intel's ifc is introduced, it can be used with "cfortran.h" without modification only if it uses one of the existing conventions for the Fortran/C interface. These conventions include how strings arguments are passed from Fortran to C and how functions in C are named from Fortran (e.g. by appending or prepending "_"). If your Intel Fortran compiler has documentation on interfacing Fortran and C, and it uses the same conventions as another compiler, then you might only need to include the right C compiler flag, for example "CFLAGS=-Df2cFortran" if it uses the same conventions as the f2c or g77 compilers. If you're lucky, one of these might just work: -DDECFortran -Dlynx -DhpuxFortran800 -Df2cFortran -DpgiFortran -DNAGf90Fortran -DAbsoftUNIXFortran -DAbsoftProFortran -DCLIPPERFortran I'll contact Burkhard Burow <address@hidden> to see if he knows how to support the Intel ifc compiler with cfortran.h. --Russ _____________________________________________________________________ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu