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: Crystal Shaw <address@hidden> >Subject: Re: 20010821: building netCDF on 64-bit machines >Organization: NCSA >Keywords: itanium, 64-bit platforms Crystal, > You have been very helpful! In the nc_test directory, got stuck in the > nc_get_vars_text. Most of the comparisons went thru very fast until it > hits get_vars_text. Need to work with the system people to get the > debugger. Even without the debugger, you can stick print statements in the function test_nc_get_vars_text(void) in nc_test/test_get.c to see where it's getting stuck. By just running "make test" in that directory after a few times, you should be able to narrow the problem down to a single loop or a small block of statements. Another thing you could try is to turn off the optimizer or at least lower the level of optimization, using a C compiler flag something like -O0 or -O1 (I don't actually know what compiler flags your compiler uses). In my experience, bugs in new compilers often occur at higher optimization levels, since vendors are initially trying to achieve speed at the expense of correctness. You might just try compiling libsrc/putget.c and nc_test/test_get.c with no optimization at all and see if the problem goes away, or check other compiler flags to see if there's any special optimizations or shortcuts you can turn off in compiling one or both of those files. > The nctest directory is core dumping, the last print out is > Testing ncvarputg. It seems related to the nc_test problem??? Yes, the nc_test tests are fairly rigorous tests of the netCDF-3 interface. The nctest directory tests the netCDF-2 interface, which is built on top of the netCDF-3 interface, so if the nc_test test is failing, the nctest test would probably fail too. The fact that nctest is failing makes it more likely the problem is in compiling libsrc/putget.c, since that would be used by nctest also. > The fortran/test and f90/test got many errors, does it mean the library > wasn't compiled correctly? Will try to compile the library again. Since the Fortran interface is just a thin layer over the netCDF-3 C interface, that would also likely fail if libsrc/putget.c were incorrectly compiled. > I know it is like walking in the dark, any suggestions are appreciated. > > IF I could get an account on the system, would you or someone else be > able to help us port, so we could get wrf going there, assuming there > is still going to be a supercomputing conference. If after trying the above you are still having troubles with the port, and we had some reason to believe it's not a compiler bug, we could try to help isolate the problem. But debugging a new compiler for the vendors can be a great sink of time ... --Russ _____________________________________________________________________ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu