Ok, I think this one is fixed.

I tested in 3 modes.

1) no macports in PATH.  Uses /usr/bin/ruby and compiles libffi from
source, because /usr/lib/libffi is dodgy.

2) macports in PATH, using /usr/bin/ruby.  Links against macports
libffi, found via macports pkg-config

3) macports in PATH, using macports ruby.  Links against macports libffi.

Jeremy, can you update to ffi master and test it on your setup?

2009/12/10 Jeremy Hinegardner <jeremy@hinegardner.org>:

> I just tried updating to 0.5.4 and ended up with this:
>
>    http://pastie.org/736768
>
> Doing some digging into the code reveals that in the extconf.rb it fails
> to find the 'ffi.h' header, but the link tests for ffi_call and
> ffi_prep_closure succeed so libffi_ok is true in extconf.rb.
> When the extension builds, it fails because ffi.h is not in the include
> path.
>
> It looks to me as if ffi already exits on my OSX
> (/usr/include/ffi/ffi.h), but but it is version 2.1 instead of the
> shipped version 3.0.6 of ffi with gem version 0.5.4
>
>    % grep VERSION /usr/include/ffi/ffi*
>    /usr/include/ffi/fficonfig.h:#define PACKAGE_VERSION "2.1"
>    /usr/include/ffi/fficonfig.h:#define VERSION "2.1-pyobjc"
>
> Adding "/usr/include/ffi" to the find_header() call results in conflicts
> on the PACKAGE_BUGREPORT, PACKAGE_NAME, PACKAGE_STRING, PACKAGE_TARNAME,
> and PACKAGE_VERSION declarations.
>
> I was able to work around the issue for me with the attached patch, but
> it is probably not the correct way to deal with this issue.
>
> enjoy,
>
> -jeremy
>
> --
> ========================================================================
>  Jeremy Hinegardner                              jeremy@hinegardner.org
>
>