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

20030506: Help compiling readgeneral.f w/udunits on DEC 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: 20030506: Help compiling readgeneral.f w/udunits on DEC Alpha
  • Date: Tue, 06 May 2003 09:11:44 -0600
Lisa,

>Date: Mon, 5 May 2003 15:46:09 -0700 (PDT)
>From: Lisa Lehmann <address@hidden>
>Organization: University of California at San Diego
>To: Steve Emmerson <address@hidden>
>Subject: Re: 20030505: Help compiling readgeneral.f w/udunits on DEC Alpha 

The above message contained the following:

> I changed the name from udunits.inc to udunits.F.   I modified
> our code to reflect the change.  Same error message.
> yasawa> f77 t.F -lnetcdf -ludunits
> f77: Warning: /usr/local/include/udunits.F, line 27: Bad # preprocessor
> line
> #ifndef PTR
> -^
> f77: Warning: /usr/local/include/udunits.F, line 28: Bad # preprocessor
> line
> #define PTR integer
> 
> etc etc.

I did find the following in our support-email archive:

    http://www.unidata.ucar.edu/cgi-bin/msgout?/glimpse/udunits/471

It describes a similar problem but for a Red Hat Linux system.
Apparently, I fixed the problem by logging onto the system and manually
modifying the file.  Unfortunately, I don't recall what I did.

I believe, however, that I would have tried the following:

    1.  Change the "include" directives in readgeneral.f, i.e,.

            include '/usr/local/include/udunits.F'

        to a C preprocessor syntax, e.g.,

            #include "/usr/local/include/udunits.F"

        where the hash character (#) is in column 1.

    2.  Change the name of "readgeneral.f" to "readgeneral.F".  This might
        cause the compiler to correctly preprocess the file.

Please let me know if this helps.

Regards,
Steve Emmerson