[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 15:08:32 -0600
John,

> no joy...
> 
> I get the following complaints from patch:
> 
> |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: libsrc/netcdf.h.in
> Patching file libsrc/netcdf.h.in using Plan A...
> Hunk #1 succeeded at 16.
> Hunk #2 failed at 278.
> Hunk #3 failed at 288.
> 2 out of 3 hunks failed--saving rejects to libsrc/netcdf.h.in.rej
> Hmm...  The next patch looks like a new-style context diff to me...
> The text leading up to this was:
> 
> 
> 
> etc... about half of the patches fail and final compilation has many
> errors and tests fail.

I just tried uncompressing and untarring the current distribution from

    ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf.tar.Z

(which is a symbolic link to  netcdf-232pl2.tar.Z in the same directory),
then applying patches 3 and 4 from the same ftp directory

    2.3.2-patch3
    2.3.2-patch4

and there were no patch failures; all the patches succeeded.  I would guess
you are seeing problems for one of the following reasons:

  1.  You tried to patch a source distribution that had already been
      modified from the original 2.3.2pl2 distribution, and the patch
      program couldn't handle the differences, or

  2.  You have a different version of "patch" than we are using, and so our
      patch files that were built and tested for our "patch" program don't
      work with your "patch" program.  Unlikely as this last possibility
      seems, we did see a similar problem once before caused by the use of a
      very old (pre-1988) version of "patch".  Here's the version of "patch"
      I have, which is output by "patch -v":

        % patch -v
        $Header: patch.c,v 2.0.2.0 90/05/01 22:17:50 davison Locked $
        Patch level: 12u7

      and our sources show this was built from Larry Wall's Patch Kit,
      Version 2.0.  I should get version 2.1 from
      ftp://prep.ai.mit.edu/pub/gnu/patch-2.1.tar.gz and try it on our
      patches, but I'm skeptical that it would fail when version 2.0
      succeeded.

I'm interested in the resolution of this problem, so please let me know if
there's something else I can do to help.

--Russ

______________________________________________________________________________

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