OpenMCL uses a set of Berkeley DB v1 database files which contain foreign type, record, constant, and function definitions derived from the Linux (or Darwin) header files. An archive containing these database files (and the shell scripts that were used in their creation) is available.
Not surprisingly, Linux and Darwin use different interface files.
For LinuxPPC:
For DarwinPPC:
This archive (like OpenMCL binary and source distributions) should be extracted in the parent directory of the CCL directory. The LinuxPPC archive will create or overwrite the contents of the "ccl:headers;" directory; the DarwinPPC archive will create or populate "ccl:darwin-headers;".
Note that prior to version 0.9, OpenMCL used the GDBM database engine (vice Berkeley DB) and the "ccl:headers;" directory was laid out differently. When upgrading from the old-style database to the new, it may be necessary to remove or rename the "ccl:headers;" directory before extracting the archive.
OpenMCL defines reader macros that consult these databases:
#$foo looks up the value of the constant definition of FOO
#_foo looks up the foreign function definition for FOO
In both cases, the symbol FOO is interned in the "OS" package, for which "LINUX" or "DARWIN" is a nickname. The #$ reader macro has the side-effect of defining FOO as a constant (as if via DEFCONSTANT); the #_ reader macro has the side effect of defining FOO as a macro which will expand into an (EXTERNAL-CALL form.)
It's important to remember that the side-effect happens when the form containing the reader macro is read. Macroexpansion functions that expand into forms which contain instances of those reader macros don't do what one might think that they do, unless the macros are expanded in the same lisp session as the reader macro was read in.
In addition, references to foreign type, structure/union, and field names (when used in the RREF/PREF and RLET macros) will cause these database files to be consulted.
Since the OpenMCL sources now contain instances of these reader macros (and references to foreign record types and fields), it's now necessary to install the interface database before compiling OpenMCL.
Other issues:
Although the interface translation process preserves the case of external symbols, the identifiers used as database keys are mapped to uppercase. (This means that if there are distinct foreign symbols that differ only in case, only one of them will be accessible via the database.) Ultimately, this issue needs to be addressed; ideally, it'll be addressed in some way that doesn't force users to pay more attention to case issues than is necessary.)
The Linux databases are derived from a somewhat arbitrary set of Linux header files. Linux is enough of a moving target that it may be difficult to define a standard, reference set of interfaces from which to derive a standard, reference set of database files.
This seems to be less of an issue with Darwin.
For information about building the database files, see here.