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.
> Date: Mon, 25 Nov 1996 16:07:21 -0500 (EST) > From: Harvey Seim <address@hidden> > To: Russ Rew <address@hidden> > Subject: Re: 961125: not working on SGI r10000 Harvey, > Russ - thanks for answering so quickly. It looks like I may have answered too quickly (see below). > When I do the default make, > then run make test, I get this output: [ Output showing all tests successful] > It looks like there are no flags set for the f77 compilation in the > test, not even the level 2 optimization. This is simply > unexceptable, my LES is painful slow unless it's optimized. Does > this mean an I/O interface to netCDF isn't going to work at > present? It is because of the r10000? I know of a site running > r8000 that did the default implementation, got 64bit libraries, and > hasn't had any problems (at APL/UW). I'll check out the web site > for further advice, thanks. I don't think there should be any problem turning on level 2 optimization when compiling the netCDF library with FFLAGS="-O2" or something similar. Also, feel free to specify any level of optimization with programs you compile separately and link with the netCDF library, even if the latter is not optimized; as far as I know, there is no incompatibility introduced by linking together object modules that are compiled at different optimization levels. Using different optimization flags is OK, but that's very different from using flags that change the way the basic types are represented in memory between a library and a program compiled to use it. I think the SGI documentation states that programs compiled with "-64" must use libraries compiled with "-64" and similarly for "-n32". From your question this morning, I thought that that the netcdf library must have been built with "-n32" (which would allow for sharing between different SGI architectures) but the program you were trying to compile and link with it used "-64". I may have given you bad advice, because looking at the error message again: > stretchz.o -lnetcdf -o cfd.x > ld64: FATAL 12: Expecting /usr/local/lib64/libnetcdf.a objects: it now appears that this had nothing to do with the "-64" vs. "-n32" issue; instead I think you just had not installed the netcdf library in the place where f77 was looking for it. The library gets installed with "make install", and it looks like you need to either tell it where to look with ... -L /usr/local/heres/where/it/is -lnetcdf ... on your f77 link line, or make sure it gets installed in /usr/local/lib64/ by either copying it there or running make install LIBDIR=/usr/local/lib64 from the netcdf/libsrc/ directory after the library and Fortran jackets are built. Sorry I jumped to the conclusion that it was a "-64" "-n32" mismatch. --Russ