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

970131: Netcdf under NeXTstep

Steven,

> To: address@hidden
> From: Steven Howell <address@hidden>
> Subject: netCDF 2.4.3 on a NeXT
> Organization: University of Hawaii
> Keywords: 199701310220.TAA15014

In the above message you wrote:

> GMT). My setup is a NeXT Cube (25MHz 68040 w/28 MB RAM) running
> NeXTSTEP 3.2. I need only the c interface, not the c++ or fortran
> versions. I realize that NeXTSTEP is no longer a supported operating
> system, but I had no trouble installing an earlier version (1.58, I
> think).
> 
> I ftp's the netCDF 2.4.3 distribution and ran configure, which had
> problems with the lack of a uname command, so I got the gnu shell
> utilities, and after much mucking about, got it to compile uname.

Good solution.

> 
> > netcdf-2.4.3(52) uname -m
> > NeXT_X15
> > netcdf-2.4.3(53) uname -r
> > 0
> > netcdf-2.4.3(54) uname -a
> > NEXTSTEP hohum 0 3 NeXT_X15 MC68040
> > netcdf-2.4.3(55) 
> 
> I'm puzzled by the release number of 0, as I think it should be 3.2. I
> also altered the CUSTOMIZE file to the following:
> 
> > # C++ compiler (default is system-dependent).  Define as the empty 
> > # string to avoid building the C++ interface.
> >   CXX=""
> > #
> > # Installation prefix (default is `..'):
> >   prefix=/usr/local/netcdf
> > #
> > # No fortran compiler, so define as empty string.  sgh 1/30/97
> >   FC=""
> 
> The configure script still failed to execute properly, quitting with the 
> statement
> 
> > expanding `include's in file `fortran/Makefile'
> > expanding `include's in file `cxx/Makefile'
> > s: No such file or directory
> > src(58)
> 
> I traced this to a problem with cxx/Makefile.in (or perhaps a bug in
> sscanf). The conftest.c (from the configure script) program line
> 
> >     if (sscanf(buf, "include%*[ \t]%s", path) == 1) {
> 
> mishandled the line 
> 
> > includes    = -I../libsrc
> 
> in cxx/Makefile.in, returning the final "s" from "includes" in the
> variable path (the Makefile.in line should have been ignored).

Looks like a bug in sscanf().  With the given input string, it shouldn't
assign to the `path' variable, so the return code should be 0.

> After
> several unsuccessful attempts to fix the problem by altering the
> conversion specification string in the sscanf statements, I changed
> "includes" to "cppincludes" in cxx/Makefile.in:

Good solution.  (You're pretty good!)

> 
> > libdir              = ../libsrc
> >
> > cppincludes = -I../libsrc
> >
> > MANIFEST    = Makefile.in README depend example.c example.cc \
> >               nctst.cc ncvalues.cc ncvalues.hh netcdf.cc netcdf.hh \
> >               expected expected.dos cxxdoc.tex cxxdoc.ps \
> >               djgpp32.mak emx.mak
> > defines     =
> > CPPFLAGS    = $(cppincludes) $(defines) @CPPFLAGS@
> > CXXCPPFLAGS = $(cppincludes) $(defines) @CXXCPPFLAGS@
> > CXXFLAGS    = @CXXFLAGS@
> 
> At that point, configure completed execution without any obvious
> error messages. However, make failed in a way I haven't been able to
> resolve:
> 
> > src(60) make all
> > making `all' in directory /hohum1/users/steve/netCDF/netcdf-2.4.3/src/port
> > 
> > 
> > returning to directory /hohum1/users/steve/netCDF/netcdf-2.4.3/src
> > 
> > 
> > making `all' in directory /hohum1/users/steve/netCDF/netcdf-2.4.3/src/xdr
> > 
> > 
> > returning to directory /hohum1/users/steve/netCDF/netcdf-2.4.3/src
> > 
> > 
> > making `all' in directory /hohum1/users/steve/netCDF/netcdf-2.4.3/src/libsrc
> > 
> > cc -c -fpic -O -I/hohum1/users/steve/netCDF/netcdf-2.4.3/src/xdr array.c
> > cc -c -fpic -O -I/hohum1/users/steve/netCDF/netcdf-2.4.3/src/xdr attr.c
> > cc -c -fpic -O -I/hohum1/users/steve/netCDF/netcdf-2.4.3/src/xdr cdf.c
> > cc -c -fpic -O -I/hohum1/users/steve/netCDF/netcdf-2.4.3/src/xdr dim.c
> > cc -c -fpic -O -I/hohum1/users/steve/netCDF/netcdf-2.4.3/src/xdr file.c
> > cc -c -fpic -O -I/hohum1/users/steve/netCDF/netcdf-2.4.3/src/xdr iarray.c
> > cc -c -fpic -O -I/hohum1/users/steve/netCDF/netcdf-2.4.3/src/xdr error.c
> > cc -c -fpic -O -I/hohum1/users/steve/netCDF/netcdf-2.4.3/src/xdr globdef.c
> > cc -c -fpic -O -I/hohum1/users/steve/netCDF/netcdf-2.4.3/src/xdr putget.c
> > cc -c -fpic -O -I/hohum1/users/steve/netCDF/netcdf-2.4.3/src/xdr putgetg.c
> > cc -c -fpic -O -I/hohum1/users/steve/netCDF/netcdf-2.4.3/src/xdr sharray.c
> > case `uname -sv` in  'AIX 3')  CFLAGS=`echo -fpic -O | sed 
> 's/-O[23]//g;s/-O//g'`;  cc -c $CFLAGS 
> - - -I/hohum1/users/steve/netCDF/netcdf-2.4.3/src/xdr string.c;  ;;  *)  cc 
> -c 
> - - -fpic -O -I/hohum1/users/steve/netCDF/netcdf-2.4.3/src/xdr string.c;  ;;  
> esac
> > cc -c -fpic -O -I/hohum1/users/steve/netCDF/netcdf-2.4.3/src/xdr var.c
> > cc -c -fpic -O -I/hohum1/users/steve/netCDF/netcdf-2.4.3/src/xdr 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
> > case "" in  '') ;;  *)  ar rucv libnetcdf.a ;;  esac
> > ranlib libnetcdf.a
> > 
> > returning to directory /hohum1/users/steve/netCDF/netcdf-2.4.3/src
> > 
> > 
> > making `all' in directory /hohum1/users/steve/netCDF/netcdf-2.4.3/src/ncdump
> > 
> > cc -c -O -I../libsrc   -I/hohum1/users/steve/netCDF/netcdf-2.4.3/src/xdr 
> ncdump.c
> > cc -c -O -I../libsrc   -I/hohum1/users/steve/netCDF/netcdf-2.4.3/src/xdr 
> vardata.c
> > cc -c -O -I../libsrc   -I/hohum1/users/steve/netCDF/netcdf-2.4.3/src/xdr 
> dumplib.c
> > cc -o ncdump -O ncdump.o vardata.o dumplib.o ../libsrc/libnetcdf.a
> > ld: Undefined symbols:
> > __GLOBAL_OFFSET_TABLE_
> > *** Exit 1
> > Stop.
> > *** Exit 1
> > Stop.
> 
> I don't know what GLOBAL_OFFSET_TABLE is. I cannot find it in any of
> the netCDF source code, nor in any of the standard header files on my
> nctest directories.
> 
> Do you have any suggestions?

I don't know what __GLOBAL_OFFSET_TABLE_ is either.  I suggest asking
the NextOS programmer newsgroup <comp.sys.next.programmer>.  It's still
active.  It just used Deja News <http://www.dejanews.com/> to search the
newsgroup for GLOBAL_OFFSET_TABLE but it didn't show up.

> I did a search on your netCDF mailing
> list for nextstep and nextos, but this particular difficulty wasn't
> mentioned. I'll ask some of the people who wrote whether they
> had any success. I'm curious whether the results from uname are
> enough different from expected to foul things up.

I don't think so.

> Is there any more
> useful information I can give you?

Probably, but since it would require that I know what
__GLOBAL_OFFSET_TABLE_ is, the information wouldn't do much good, I'm
afraid.

> As an alternative, is there an
> older version of netCDF available that will compile on a NeXT? GMT
> documentation states that version 2.3 or newer is required.

Sorry, there's no older version available.  And the caveat from GMT
indicates that the older version wouldn't work anyway.

Try the newsgroup.  Please let me know what you discover.

--------
Steve Emmerson   <address@hidden>