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

Re: 950523: netcdf build problem on DEC Alpha 2100

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.

  • Subject: Re: 950523: netcdf build problem on DEC Alpha 2100
  • Date: Wed, 24 May 1995 19:11:52 -0600
John,

> > I can't reproduce the problem you are seeing with the patches.  Using
> > version 2.1, which is the latest version of patch from the GNU archives
> > that I just built, everything succeeds, as the appended patch output
> > shows.
 ...
> very strange... the only other possibility is that something funny
> happened to the patch files.  Did you use the patch files from ftp
> directory?

Yes, I did.  I just tried /bin/patch on an OSF/1 V3.0 alpha system and
verified that it does indeed fail on patch3, although the failure I saw was
that it didn't seem to know what to patch, so it prompted interactively for
which file to patch:

    % patch -v
    OSF/1 version 1.0 - based on:
    Header: patch.c,v 2.0.1.6 88/06/22 20:46:39 lwall Locked
    Patch level: 12
    % patch < ~ftp/pub/netcdf/2.3.2-patch3
    Hmm...  Looks like a new-style context diff to me...
    The text leading up to this was:
    --------------------------
  ...
    |diff -c1 -r libsrc/netcdf.h.in
    |*** oldlibsrc/netcdf.h.in      Tue Jun  8 13:20:36 1993
    |--- libsrc/netcdf.h.in Wed Jul 21 12:36:23 1993
    --------------------------
    File to patch: 

So I built the GNU patch-2.1 on the alpha OSF/1 (using cc) and it worked
fine!

This is the only case I have seen of a vendor-supplied patch program
failing to properly apply patches.

> If you can believe it the license on my fortran compiler expired on
> the 23rd!  I need to update the licenses and do some other things so I
> probably won't try to get back to the full distribution installation
> for a week.
> 
> the c++ part compiles and links without complaint.  My quick test
> attempt, using gcc, yields the following:
> 
> > make test
> gcc -c -g -I../libsrc  nctst.cc
> gcc -c -g -I../libsrc  netcdf.cc
> gcc -c -g -I../libsrc  ncvalues.cc
> ar rcuv libnetcdf_c++.a netcdf.o ncvalues.o
> a - netcdf.o
> a - ncvalues.o
> s - creating symbol hash table. Wait...
> s - done
> # If ranlib isn't found, that's OK
> ranlib libnetcdf_c++.a
> s - creating symbol hash table. Wait...
> gcc nctst.o libnetcdf_c++.a -L../libsrc -lnetcdf -L. -lnetcdf_c++
> -lg++ -o nctst
> ./nctst > test.out
> ncendef: xdr_NC_array: loop
> *** Exit 3
> Stop.

Apparently gcc is misconfigured on our alpha, so I can't duplicate this
right now.  However, I would think you should be using "g++" rather than
"gcc" for the compiler.  Have you tried compiling the C++ interface by
invoking

   make CCC=g++

from the patched c++ source directory?

______________________________________________________________________________

Russ Rew                                           UCAR Unidata Program
address@hidden                              http://www.unidata.ucar.edu