|Version 5 (modified by gb, 4 years ago)|
Obtaining and building the FFI translator (FFIGEN)
The easiest way of obtaining a copy of the FFIGEN program is to check out its sources from svn, possibly obtain GCC sources from gcc.gnu.org or a mirror site, and build a copy. (The FFIGEN "sources" are a Makefile, some patches to the GCC frontend, and a few shell scripts and auxiliary file. For most platforms (other than Win64 and OSX Leopard) FFIGEN's built by patching GCC 4.0. For OSX Leopard, it's built by patching an Apple GCC that contains support for Apple's ObjC 2.0 extensions. For Win64 ... as of this writing, it's sort of cobbled together as a cross-platform tool hosted on Linux.
Building the trunk version (for Linux, FreeBSD, Solaris, Win32)
0. Ensure that your system has a working C compiler and toolchain, the m4 macro processor, and GNU make installed. (The "toolchain" components might include things like "flex", "yacc/bison" ... whatever would be needed to build GCC.)
1. Obtain copies of "gcc-core-4.0.0.tar.bz2" and "gcc-objc-4.0.0.tar.bz2" from ftp://gcc.gnu.org or a mirror site.
2. Checkout the ffigen "sources":
shell> svn co http://svn.clozure.com/publicsvn/ffigen4/trunk/ffigen4
3. Copy the gcc tar archives to the ffigen4 directory created by the checkout, cd to that directory, and invoke the "make" program
shell> cp gcc*4.0.0.tar.bz2 ffigen4 shell> cd ffigen4 shell> make
If "make" doesn't invoke GNU make on your system, use whatever command (often "gmake") GNU make is installed as.
That should build a tar archive (named something like "ffigen-bin-PLATFORM-DATE.tar.gz") in the ffigen4 directory (after untarring the gcc source archives, applying some patches to them, and building a modified version of the GCC frontend.) If the contents of that archive are extracted in some directory that has a "bin" directory that's on your shell's search path, then the "h-to-ffi.sh" shell script will be somewhere where it can be found by "populate.sh" scripts. (E.g., assuming that "/usr/local/bin is on your shell's search path, the command:
shell> sudo tar xvf ffigen-bin-PLATFORM-DATE.tar.gz -C /usr/local
will install the h-to-ffi.sh script in /usr/local/bin and other components in other subdirectories of /usr/local
If something goes wrong during the "make" process (e.g., because some tool needs to be installed), a subsequent "make" invocation will start over from the beginning (e.g., it always tries to do a full, clean build.) Depending on things like CPU and disk speed, the full build likely takes between 5 and 15 minutes.)
Building a Leopard version with ObjC 2.0 support
This is conceptually similar to the mainline GCC 4.0 build process described above, only the "sources" (Makefile, patches, etc.) are maintained on an svn branch, patch an Apple GCC release (that contains ObjC 2.0 extensions) rather than the main GCC 4.0 release, and the svn repository contains the GCC source archive. (It wasn't clear whether Apple would continue to offer sources for this particular GCC release, or whether URLs would change, so it seemed best to keep the tarball in the repository.) The incantations are:
1. Check out the Apple-specific svn branch:
shell> svn co http://svn.clozure.com/publicsvn/ffigen4/branches/ffigen-apple-gcc-6465/ffigen4
Note that after svn announces that several small files have been checked out, there may be a substantial delay while it checks out the gcc source archive. Be sure to wait (however long you'd wait for a ~40MB file to download) for the checkout to complete.
2. Build the installation archive:
shell> cd ffigen4 shell> make
3. Install the installation archive as above.
Win64 support in gcc is being added to version 4.4. It's still a bit of a moving target and there have been issues in getting gcc to build natively on Win64. When this stabilizes a bit, there'll probably be a Win64-specific branch in the ffigen4 tree.
At some point in the relatively near future, the mainline version of GCC will include Win64 support and Apple's ObjC 2.0 extensions, and it should be possible to build FFIGEN for all platforms from patches relative to that GCC version. (That GCC version is likely to incidentally depend on some additional libraries which enable it to do compile-time arithmetic more accurately and portably, so the build process will get a bit more complicated.)