[MITgcm-devel] the "stubs" idea for MNC

[Chris Hill]

Oh well. I must admit I was surprised when I asked and you said there
weren't any strings going over the interface. 

I can think of one fix but it is probably too painful to try. It would look
like this -

mnc_foo()
call stubfront_nf_XXX(....., string_var,  ...)
return

stubfront_nf_XXX(...., string_var, ...) 
 int_var=change_string_to_ints(string_var)
 call stubback_nf_XXX(....,int_var,...)
return
end

stubback_nf_XXX(...,int_var,....)
 string_var=change_ints_to_string(int_var)
 call nf_XXX(..., string_var, ...)
End

- stubfront_nf_XXX would be compiled with the compiler in effect for mitgcm

- stubback_nf_XXX would be compiled with the gnu and would be in usr/local
along with netCDF compiled with gnu.


Chris


> -----Original Message-----
> From: mitgcm-devel-bounces at mitgcm.org 
> [mailto:mitgcm-devel-bounces at mitgcm.org] On Behalf Of Ed Hill
> Sent: Tuesday, July 27, 2004 2:45 PM
> To: MITgcm-devel
> Subject: [MITgcm-devel] the "stubs" idea for MNC
> 
> 
> Hi Alistair & Chris,
> 
> Executive summary:
> 
>   The stubs idea doesn't work.
>   We must compile a NetCDF library for EACH COMPILER.
> 
> 
> Details:
> 
>   Get my implementation of the stubs idea for MNC at:
> 
>     http://mitgcm.org/eh3/MNC/mnc_stubs.tar.gz
> 
>   and use it as a drop-in replacement for pkg/mnc.
> 
>   Try out the code and notice that:
> 
>     1) it compiles cleanly (so I got all the name mangling bits 
>        right), but
> 
>     2) it does not run.
> 
>   The reason is that the NetCDF calls make extensive use of
>   strings on both sides of the Fortran/C interface.  The
>   NetCDF implementors solved the problem of passing strings
>   by using (including a copy of) the "cfortran.h":
> 
>     http://www-zeus.desy.de/~burow/cfortran/
> 
>   header as part of their C library.
> 
>   The upshot of all this seems to be that, unless we're using
>   two compilers that are binary compatible with each other,
>   we must compile the NetCDF library for each compiler.  
>   Alternatively, we're going to have to write a compatibility
>   layer thats at least as clever as "cfortran.h" because it
>   will have to know how the different compilers encode strings
>   (with *ONLY* the knowledge we can glean from a previously-
>   compiled library--remember that "cfortran.h" has the
>   advantage of being able to generate C code to work with the
>   Fortran interface, not the other way around) and then
>   translate between them.
> 
> Ed
> 
> --
> Edward H. Hill III, PhD
> office:  MIT Dept. of EAPS;  Rm 54-1424;  77 Massachusetts Ave.
>              Cambridge, MA 02139-4307
> emails:  eh3 at mit.edu                ed at eh3.com
> URLs:    http://web.mit.edu/eh3/    http://eh3.com/
> phone:   617-253-0098
> fax:     617-253-4464
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
>