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

Re: netCDF installation problems on VAX/Alpha

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: netCDF installation problems on VAX/Alpha
  • Date: Fri, 03 Feb 95 11:01:37 -0700
Stan,

>From: Stan Bujnowski <address@hidden>
>Organization: M.D. Anderson Cancer Center
>Subject: netCDF installation problems on VAX/Alpha 
>Keywords: 199502031618.AA19961 

    In the above message you wrote:

>We tried to install netCDF on the VAX (and later on an Alpha as well)
>without success.

    Because we don't have in-house access to a VMS platform (let alone
a VMS/Alpha one) I'm afraid you're going to be pretty much on your own.
We might be able to give some general guidance and advice, but that's
about it (see below).

>When doing a @make in [.xdr] directory we got the following error messages:
>Suggestions?
>
>CHOPIN::syslib>sh def
>  PUMA_USER:[DRK.NETCDF.NETCDF-2.3.2.XDR]
>CHOPIN::syslib>@make
...
>at line number 48 in file PUMA_USER:[DRK.NETCDF.NETCDF-2.3.2.XDR]TYPES.H;1
> 
>long ntohl(long);
>.....^
>%CC-E-NOTCOMPAT, In this declaration, the type of ntohl is not compatible with
>t
>he types of previous declarations of ntohl.
>at line number 21 in file PUMA_USER:[DRK.NETCDF.NETCDF-2.3.2.XDR]TYPES.H;1
> 
>long htonl(long);
>.....^
>%CC-E-NOTCOMPAT, In this declaration, the type of htonl is not compatible with
>t
>he types of previous declarations of htonl.
>at line number 22 in file PUMA_USER:[DRK.NETCDF.NETCDF-2.3.2.XDR]TYPES.H;1
> 
>typedef unsigned char   u_char;
>........................^
>%CC-E-NOLINKAGE, In this declaration, u_char has no linkage and has a prior
>decl
>aration in this scope at line number 41 in file
>SYS$COMMON:[SYSLIB]DECC$RTLDEF.T
>LB;1.
>at line number 40 in file PUMA_USER:[DRK.NETCDF.NETCDF-2.3.2.XDR]TYPES.H;1
> 
>typedef unsigned short  u_short;
>........................^
>%CC-E-NOLINKAGE, In this declaration, u_short has no linkage and has a prior
>dec
>laration in this scope at line number 37 in file
>SYS$COMMON:[SYSLIB]DECC$RTLDEF.
>TLB;1.
>at line number 41 in file PUMA_USER:[DRK.NETCDF.NETCDF-2.3.2.XDR]TYPES.H;1
> 
>typedef unsigned long   u_long;
>........................^
>%CC-E-NOLINKAGE, In this declaration, u_long has no linkage and has a prior
>decl
>aration in this scope at line number 39 in file
>SYS$COMMON:[SYSLIB]DECC$RTLDEF.T
>LB;1.
>at line number 43 in file PUMA_USER:[DRK.NETCDF.NETCDF-2.3.2.XDR]TYPES.H;1
> 
>typedef char *  caddr_t;
>.............^
>%CC-E-NOLINKAGE, In this declaration, caddr_t has no linkage and has a prior
>dec
>laration in this scope at line number 34 in file
>SYS$COMMON:[SYSLIB]DECC$RTLDEF.
>TLB;1.

    Looks like VMS has changed considerably since we last had access to it.

    As the first step, I suggest just trying to build the program xdrtest in
the xdr subdirectory:

    $ cc /opt/nodebug/nolist xdrtest.c
    $ link/nodebug/notraceback/exec=XDRTEST.exe -
        xdrtest.obj, -
        sys$input/opt
            sys$library:vaxcrtl.exe/share

Then, use xdrtest to see if the DEC-supplied XDR implementation is OK
(it didn't use to be).  You can see how to do this by looking at the
`test' target in Makefile.in.

    Let me know what you discover.

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