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

Re: 961125: not working on SGI r10000

> 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