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.
>Keywords: 199509180734.AA21069 Hi Craig, > I've been trying to install netCDF on a PowerMac under the MachTen 4.0 > Unix. I have tried setting env. variables CC to the default or gcc, > CPPFLAGS to null (since I don't see -DNDEBUG as an option on this system), Although it won't make much difference, -DNDEBUG is merely setting the macro NDEBUG for C code, in particular to turn off the effect of invocations of the assert macro in C code. It's not anything platform-dependent, but has the same meaning for any C compiler. CPPFLAGS should generally be set up by the "configure" script, rather than manually. That way if any special macros have to be defined for your system that the "configure" script can detect, they will be automatically set and passed to compile steps via the Makefiles that "configure" generates. > FC to g77, others unchanged. The make all runs for awhile before dying > rather cryptically in trying to make ncdump. The log file is attached > below showing what all happens; the only other anomaly I see is a > warning about a missing tab (which doesn't make any sense when I have > looked at the Makefile referenced). While I suspect this all is a problem > in using Unix on top of a Mac, the fact that you mention in the readme that > this has been installed on a Mac (well, maybe that was GMT's (Generic > Mapping Tools) readme) led me to suspect you might have seen this > attempted before (although this version of MachTen is brand new). Since there is no error produced for ncdump, I can't tell what the problem is. Maybe the compiler is failing for some reason unrelated to the code it is compiling, e.g. running out of memory or disk space? Usually gcc produces excellent error messages, so when it fails like this, I suspect the problem is somewhere else. Do the failures always occur in compiling ncdump/dumplib.c? > Also, I have some grief with the "OS" environment variable. From > what I can see, it only controls the fortran compilation and otherwise > is unimportant--I have set it to sunos, lacking any useful info to > suggest a better course (basically no info on how g77 links to c). > If it is more important, then I need to get this fixed up. You're right, the OS macro is only important for the Fortran interface. As far as I know, no one has successfully gotten g77 to work with gcc well enough to get the netCDF Fortran interface working this way, and I don't think it's even been possible until the combination gcc 2.7.0 with g77 version 0.5.16. Anyway if you don't need the Fortran interface, you could also just follow the steps in the note below (from our "Known Problems with the netCDF Distribution" document at http://www.unidata.ucar.edu/packages/netcdf/known_problems.html): Ignoring FORTRAN Setting the variable FC (either in the environment or in the CUSTOMIZE file) to the empty string doesn't work as advertised: the FORTRAN component of the netCDF distribution is not completely ignored. The workaround is to set the FC macro in the master makefile (port/master.mk.in) to the empty string prior to running the configure script, i.e. change FC = @FC@ to FC = This will cause the FORTRAN side of the netCDF distribution to be completely ignored. This action will be unnecessary in the next release. > Anyways, thatnks for any suggestions. I am trying to get this up > to run GMT on this Mac; given how unusual this setup is, I'm not > real optimistic that you'll be able to help. We can't reproduce the problem here, so it will be difficult to provide much more help. > making `all' in directory /home/cjones/NetCDF/netcdf-232pl2/libsrc > > "Makefile", line 71: warning: Shell command needs a leading tab Since the configure-generated Makefiles are different on every platform, there is no way for us to tell what line this is referring to, unless you actually send us the Makefile. Since the subsequent compilation and building of the library in the libsrc seems to have gone OK, this can probably be ignored. > gcc -O -c -O array.c > gcc -O -c -O attr.c > gcc -O -c -O cdf.c > gcc -O -c -O dim.c > gcc -O -c -O file.c > gcc -O -c -O iarray.c > gcc -O -c -O error.c > gcc -O -c -O globdef.c > gcc -O -c -O putget.c > gcc -O -c -O putgetg.c > gcc -O -c -O sharray.c > gcc -O -c -O string.c > gcc -O -c -O var.c > gcc -O -c -O xdrposix.c > ar rcuv libnetcdf.a array.o attr.o cdf.o dim.o file.o iarray.o error.o > globdef. > o putget.o putgetg.o sharray.o string.o var.o xdrposix.o > a - array.o > a - attr.o > a - cdf.o > a - dim.o > a - file.o > a - iarray.o > a - error.o > a - globdef.o > a - putget.o > a - putgetg.o > a - sharray.o > a - string.o > a - var.o > a - xdrposix.o > ranlib libnetcdf.a > > returning to directory /home/cjones/NetCDF/netcdf-232pl2 > > > making `all' in directory /home/cjones/NetCDF/netcdf-232pl2/fortran > > ./fortc -L . -O sunos common.inc > netcdf.inc > ./fortc -L . -O sunos jackets.src > jackets.c > gcc -O -c -I../libsrc -O jackets.c > ar rcuv ../libsrc/libnetcdf.a jackets.o > c - jackets.o > ranlib ../libsrc/libnetcdf.a > > returning to directory /home/cjones/NetCDF/netcdf-232pl2 > > > making `all' in directory /home/cjones/NetCDF/netcdf-232pl2/ncdump > > gcc -O -c -I../libsrc -I../port -O ncdump.c > gcc -O -c -I../libsrc -I../port -O vardata.c > gcc -O -c -I../libsrc -I../port -O dumplib.c > *** Error code 1 > > Stop. If the library was built OK before this, you may have gotten far enough for GMT. If it doesn't use ncdump or ncgen, you could just install the library built in the libsrc directory and see if GMT is happy. ______________________________________________________________________________ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu