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

Re: 950918: netCDF on a Mac

>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