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.
> I have tried to build the libraries several ways and can't get > things to work right. If I do a default installation (just leaving > FFLAGS and CFLAGS as -O) I get the following message when I try to > compile my code that uses the netCDF commands: > f77 -col120 -64 -r4 -mips4 -r10000 -O3 ... stretchz.o -lnetcdf -o cfd.x > ld64: FATAL 12: Expecting /usr/local/lib64/libnetcdf.a objects: > ld64: Segmentation fault. Removing output file... > f77 ERROR: /usr/lib64/cmplrs/ld64 returned non-zero status 1 > *** Error code 1 (bu21) I don't see why the loader (ld) should ever dump core. I'm wondering if your compiler install is correct. Did the OS get upgraded to 6.2 without upgrading the compilers? You can discover what versions of compiler products you have installed using the 'showprods' command. % showprods c_eoe c_dev c++_dev compiler_dev ftn77_eoe ftn77_dev The products should all be version 6.2 or above. The second question is, what, if anything, is /usr/local/lib64/libnetcdf.a? % file /usr/local/lib64/libnetcdf.a As russ mentions, you should see something like /usr/local/lib64/libnetcdf.a: current ar archive containing 64-bit objects, or, you should add a -Lpath_to_netcdf_lib_directory option to your link line. > Trying to compile my source as new 32bit code made me think the > library was old 32bit output. Old 32 bit libs should link okay with new 32 bit libs. > So I tried specifying the flags to > force compilation to be 64 bit, mips4, on an r10000 (see env output > below). I believe the compiler defaults to -64 on your hardware. The other flags aren't relevant to this problem. > Then the make for netcdf bombs. > output from configure: > loading cache ./config.cache One has to be careful rebuilding netcdf upon changing compilers to delete the cache!!!!! `rm config.cache` or `make distclean`. Values like sizeof(long) are stored in the cache. Careful reading of the output of configure shows that the "change" to -64 did not change the model from the previous build, the previous build had 64 bit longs > checking size of long... (cached) 8 So, the fact that you didn't delete the cache wasn't a problem here. (But, you didn't need to rebuild, either.) > cc -o nctest -64 -mips4 -r10000 varget.o vargetg.o varput.o varputg.o vardef.o > vartests.o vputget.o vputgetg.o driver.o cdftests.o dimtests.o rec.o > atttests.o misctest.o add.o error.o emalloc.o val.o slabs.o > ../libsrc/libnetcdf.a Note that this link, like all the previous 'cc' links, was sucessful. > CC nctst.o -L. -lnetcdf_c++ -L../libsrc -lnetcdf -o nctst >ld: > Archive: ../libsrc/libnetcdf.a has no table of contents (not searched) > add one with 'ar ts' This makes me think you are accessing an old version (like maybe version 5) of CC. It can't even read 64 bit archive headers. The fact that you can't build the the CC (cplusplus) test is not on the critical path to you building a fortran application. To get this out of your face, set the environment variable CXX to the empty string, re-run `configure`, `make all`, and `make test`. I'll wager that the c language tests will suceed and the fortran jackets test (fortran/ftest) will fail in similar way to your application. If that is the case, the problem is you have an old (I'm guessing version 6.0) fortran compiler. If ftest suceeds, then your application link line is just not finding the library. ----- > Error on line 311 of write3D_nc.f: Declaration error for kdimvalues: > adjustable automatic array > Error on line 368 of write3D_nc.f: Declaration error for hold2d: > adjustable automatic array These are appear to be genuine fortran errors. The compiler is telling you something about the source code that needs to be fixed. (Perhaps this is CRAY source, which allows dynamic array sizing, but which is non-standard?) I don't know why you don't see these errors when you use -n32. Take that (and the meaningless "Expecting /usr/local/lib64/libnetcdf.a objects" diagnostic) up with SGI support. The "new" (-64) compiler is supposed to be better in some sense, so maybe it is being more strict where the old one would happily generate code from invalid source, and dump core at run time. -glenn