[Openmcl-devel] ffigen progress
james.anderson at setf.de
Thu Feb 26 04:45:22 PST 2009
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
> 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
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
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
does not place .ffi an output file where one expects (i didn't find
it in '/' either), but
> 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
> 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.
More information about the Openmcl-devel