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.
Steve, >Date: 11 Jun 1997 13:16:06 -0500 >From: "Steve Mauget" <address@hidden> >Organization: USDA >To: "Steve E" <address@hidden> >Subject: NAGS last e-mail.... >Keywords: 199706021417.IAA27579 In the above message, you wrote: > Here is the most recent (and I believe last) e-mail from NAG on this > apparent problem. He asked me if (I assume ) fortran source code for the > various subroutines was available and I told him .... > > > > source code for these subroutines are not made available, just the netcdf > > object code library file (libnetcdf.a) > > He replied: > > > Ah, you didn't tell me about that! If their library was compiled with the > native f77 compiler (which it most likely was) then there can easily be > problems when you try to create an executable. I would expect link problems > as the runtime code for the intrinsics is not there. While different fortran > compilers are usually source code compatable, they are usually not object > code compatable. You may be running into a problem because something > is not internally represented the way f90 expects it. > NAg's main products are large mathematical libraries. However, we have > different versions on any give platfor for each different compiler. For > instance, on SGI, we have separate versions for SGI f77, SGI f90, and > NAG f90. The problem is that the NAG f90 compiler error exits when we try to compile the file fortran/ftest.f. This error is independent of whether or not we link against an f90- or f77-generated library in a subsequent step. Let me know what you find in compiling my previous test code. -------- Steve Emmerson <address@hidden>