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

970210: netcdf jackets for linux absoft Fortran-77

Bill,

> To: address@hidden
> cc: address@hidden
> From: address@hidden (Bill McKie)
> Subject: netcdf jackets for linux absoft Fortran-77
> Organization: NASA/ARC
> Keywords: 199702040639.XAA14150

In the above message you wrote:

> > We recently began using netcdf under our PC linux system with a
> > commercial AbSoft Fortran-77 compiler.  We are using v2.4.3 of
> > the netcdf software.
> > 
> > During the netcdf installation process, it became apparent that the
> > Fortran interface was not working well.  (Installation test programs in
> > Fortran were not succeeding.)  And so I traced this problem to the
> > handling of character variables being passed to the netcdf jacket
> > routines from the AbSoft Fortran code.  The ...fortran/linux.m4 file 
> > was was being selected by the installation process for setting up the
> > jackets.c source, and this was not compatible with the way the AbSoft
> > Fortran compiler was generating calling sequences that contained
> > character variables.
> > 
> > The Linux AbSoft F-77 calling sequence is somewhat unique compared to
> > others that I have seen.  The gist of its calling scheme appears to
> > be:
> > 
> >  The call-by-name addresses of the actual variables appearing
> >  in the Fortran call statement are pushed onto the stack.
> > 
> >  Then additional integers are pushed onto the stack, one integer
> >  for each (and every) actual variable in the call.
> > 
> >  These extra integers are undefined except for those that
> >  correspond to character variables in the call list.  For
> >  these character variables, the integers are the length
> >  (in the sense of the Fortran len() function) of the
> >  character variable, as normally needed in C routines that
> >  are called by Fortran.

This is the strangest convention I've ever seen.

> > 
> > I was not able to come up with a nice m4 package (e.g. linux_absoft.m4)
> > for handling this cleanly for netcdf.  But I was able to hand
> > edit the jackets.c file that came out of the automated netcdf
> > install process (for linux), and change all the declarations
> > for jacket routines that are receiving 1 or more character variables.
> > And this hand-edited jackets.c file, when compiled and placed in
> > the netcdf library, is allowing us to use the netcdf package with
> > the AbSoft Fortran on our linux system at this time.
> > 
> > The scheme I used to do this was the minimal necessary for it to work.
> > (I think there were approx 26 routines to change, so I was trying to
> > minimize the manual labor in making these edits.)  I inserted as many
> > dummy extra integer arguments in the C jacket routines as there were
> > non-character variables until the last character variable in the
> > argument list.  E.g. in the case of the ncdid routine, it looks like
> > the following.
> > 
> > 
> > /*
> >  * returns the ID of a netCDF dimension, given the name of the
> >  * dimension
> >  */
> > int
> > ncdid_(ncid, dimname, rcode, trash1_bm, dimnamelen)
> >     int             *ncid;  
> >     char    *dimname;       
> >     int             *rcode; 
> >     int             trash1_bm;
> >     int             dimnamelen;
> > {
> >    :
> >    :
> > 
> > 
> > The trash1_bm is thus one of the undefined extra integers that
> > corresponds to the 1st argument ncid, which was not a character
> > variable.  It is never used and is undefined (but occupying space on
> > the stack).  Then the next extra integer was the dimnamelen as in the
> > original code, and everything was happy.  If there were additional
> > character variables, I would insert additional dummy integer arguments
> > as placeholders on the stack until reaching the last character variable
> > in the list.  Rigorously, one should probably include extra trailing
> > integer arguments for _all_ the arguments in the original calling list,
> > but it was not functionally necessary to go beyond the last character
> > variable.

I'm glad you were able to make the interface work.

> > 
> > I'm wondering if you would implement a m4 file to do this
> > automatically, so that the Linux AbSoft Fortran compiler would be
> > officially supported in the netcdf distribution?  And then folks like
> > us with Linux AbSoft Fortran wouldn't have to hand edit our jackets.c
> > file if we get an updated (or our first) version of the netcdf
> > package.

Unfortunately, it's not a question of implementing a .m4 file to handle
Linux AbSoft Fortran -- rather, the entire system would have to be
changed since it only makes allowance for extra arguments in the case of
character arguments.  Thus, it would be necessary to modify all the
m4(1) argument definitions as well as all the platform-specific m4(1)
files.

I'm afraid we don't have the resources to do that.

There are some alternatives, howerver, they include the following:

    1.  Use the freely-available f2c(1) utility instead of AbSoft
        FORTRAN.

    2.  Use the netCDF-3 package, which is currently in alpha-test.
        This package uses a different mechanism to support FORTRAN
        routines calling C functions -- one which might be easier to
        modify for a Linux/AbSoft environment.

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