[Openmcl-devel] ffigen progress

[james anderson]

hello;

i have made some progress translating the open-mpi interface.  
sufficient, that it may be worthwhile to record a few observations.

On 2009-02-25, at 04:03 , Gary Byers wrote:

> This is a mess; there should be a wiki page explaining this.

that would be nice. it was more than five years ago, the last time i  
did this - with mcl, but i recall a similarly tentative process.

>
> The easiest way to obtain a version of ffigen that works (on most  
> platforms;
> see below)  is to build it yourself from svn.
>
> For most platforms, you can do:
>
> [... useful things ...]

i followed these instructions. as my "gcc --version" yielded 'build  
5370', i used the trunk sources.
they did work, but it was important to follow them literally, in that  
the "4.0.0" sources were required, even though my gcc is actually  
"4.0.1".

i then tried both versions. any differences between the from-source  
ffigen and the 2005-05-17 version seem to not be significant in my case.

i observed the following issues:

- in the cases where a warning appears, that the float.h and/or  
stdarg.h files are not found - eg. "ccl:darwin-headers;gl;", the  
warning no longer appears if one adds an '-I' directive in the CLAGS  
to add the architecture-specific gcc include sub-directory from the  
SDK tree.
  i surmise, that this is needed to satisfy the delegation in the  
generic .h files and that something like it is present in the actual  
build CFLAGS for the library.

- one cannot presume that any given .h file includes all of its  
prerequisites. neither directly nor transitively.
  this appears to have been the cause for endless syntax errors,  
which arise when one naively processes individual header files.
  rather than process individual files, one must create a skeleton,  
which emulates the effect of compiling a library source file with  
respect to its include files.

- neither can one presume that the library's installed header files  
are sufficient to produce this effect. in the case of open-mpi, the  
installed "mpi.h" file references several types, but it does not  
define them. it declares only type definitions for pointers to  
several structure types, but does not declare the structure types  
themselves. while this does not appear to prevent a C application  
from passing such types as opaque data, the ccl compiler rejects such  
references, with the indication, that it does not know the respective  
structure's size. in order to accomplish a complete translation of  
such interface files, one must identify a library C file which  
references the required type and tailor a skeleton file to matched  
CFLAGS, in order establish the exact required header inclusion paths.

- if one places such skeleton files in the given "CCL:subdir;C;"  
directory with the populate script, they must be designated on a  
populate.sh command line by their full path name. a command like
   h-to-ffi.sh ./mpi_wrapper.h
does not place .ffi an output file where one expects (i didn't find  
it in '/' either), but
   h-to-ffi.sh `pwd`/mpi_wrapper.h
does.



>
> Building ffigen from source takes a few (for some value of "a few")
> minutes, as does doing the svn checkout and the gcc download.

many fewer than figuring out how to resolve the other issues which i  
describe above.

> An
> ffigen binary that you build yourself on a particular system is much
> more likely to work on that system than one that I build on a
> generally similar system, so this seems like a reasonable tradeoff.

bye,