This means that ghc-tarballs is only needed on Windows

On Windows, the ranlib in the path may not be the right ranlib (it may
be the 32bit ranlib when we are making a Win64 compiler, or vice-versa).
Therefore we can't leave it up to libffi to detect the right ranlib, but
need to tell it which ranlib to use. This means that we need to find
ranlib even if we don't actually need it ourselves.

This fixes a bug with how configure re-execs itself.

On Windows, we need to keep the DLL called libffi-6.dll (rather than
libffi.dll) or Windows can't find it.

Fixes the build on platforms that default to using a directory called
lib64. Reported by Gabriel Dos Reis.

Patchset from Stephen Blackheath <stephen.blackheath@ipwnstudios.com>

* Pass -Irts/dist/build to the C preprocessor to expose libffi headers (ffi.h and ffitarget.h) to foreign import wrappers during the building process of GHC itself.
* Install libffi headers into $(ghcheaderdir) just like any other C headers. Otherwise an installed GHC can't find them when it wants to compile foreign import wrappers.
* Include libffi headers in the bindist for the same reason.

With Windows 7 in a vitrual box VM on OS X, some very odd things happen
with dates and time stamps when SSHing into cygwin. e.g. here the
"Change" time is in the past:

$ date; touch foo; stat foo
Fri Dec  2 16:58:07 GMTST 2011
  File: `foo'
  Size: 0               Blocks: 0          IO Block: 65536  regular
empty file
Device: 540aba0bh/1409989131d   Inode: 562949953592977  Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/     ian)   Gid: (  513/    None)
Access: 2011-12-02 16:58:07.414457900 +0000
Modify: 2011-12-02 16:58:07.414457900 +0000
Change: 2011-12-02 16:58:03.495141800 +0000
 Birth: 2011-12-02 16:57:57.731469900 +0000

And if we copy such a file, then the copy is older (as determined by the
"Modify" time) than the original:

$ date; touch foo; stat foo; cp foo bar; stat bar
Fri Dec  2 16:59:10 GMTST 2011
  File: `foo'
  Size: 0               Blocks: 0          IO Block: 65536  regular
empty file
Device: 540aba0bh/1409989131d   Inode: 1407374883725128  Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/     ian)   Gid: (  513/    None)
Access: 2011-12-02 16:59:10.118457900 +0000
Modify: 2011-12-02 16:59:10.118457900 +0000
Change: 2011-12-02 16:59:06.189477700 +0000
 Birth: 2011-12-02 16:57:57.731469900 +0000
  File: `bar'
  Size: 0               Blocks: 0          IO Block: 65536  regular
empty file
Device: 540aba0bh/1409989131d   Inode: 281474976882512  Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/     ian)   Gid: (  513/    None)
Access: 2011-12-02 16:59:06.394555800 +0000
Modify: 2011-12-02 16:59:06.394555800 +0000
Change: 2011-12-02 16:59:06.395532400 +0000
 Birth: 2011-12-02 16:58:40.921899600 +0000

This means that make thinks that things are out of date when it
shouldn't, so reinvokes itself repeatedly until the MAKE_RESTARTS
infinite-recursion test triggers.

The touchy program, like most other programs, creates files with both
Modify and Change in the past, which is still a little odd, but is
consistent, so doesn't break make.

We avoid calling "rm -rf" with no file arguments; this fixes cleaning
on Solaris, where that fails.

We also check for suspicious arguments: anything containing "..",
starting "/", or containing a "*" (you need to call $(wildcard ...)
yourself now if you really want globbing). This should make things
a little safer.

iWe were adding c:/... to $PATH, but : is the separator
in $PATH.

We now put the libffi objects into the RTS library, rather than trying
to mangle libffi into being a ghc package itself. It would be nicer to
 make it a separate library (but not a ghc package), but for now
 hopefully this will get the build going through on Windows again.

This allows different gcc's to be used when building different stages,
which we need to do when cross-compiling.

We were doing
    echo $(HOSTPLATFORM) | sed 's/i[567]86/i486/g'
but the only x86 value HOSTPLATFORM can have is i386.

We now tell libffi its build platform again, but we now tell it it's
$(BUILDPLATFORM) rather than $(HOSTPLATFORM).

The value --build was set to broke cross-compilier builds, and isn't
needed for regular builds.

As far as I can see this has been wrong for some time, but only bit
recently.

Fixes a rare race when both libHSffi.a and libHSffi_p.a were being built
at the same time:

"cp" libffi/dist-install/build/libffi.a libffi/dist-install/build/libHSffi.a
"cp" libffi/dist-install/build/libffi.a libffi/dist-install/build/libHSffi.a
"cp" libffi/dist-install/build/libffi.so libffi/dist-install/build/libHSffi-ghc7.1.20110115.so
cp: cannot create regular file `libffi/dist-install/build/libHSffi.a': File exists

This patch unbreaks ghci on GRSEC kernels hardened with
TPE (Trusted Path Execution) protection.

TPE forbids mmap('rwx') files opened for writes:
    fd = open (a_file_in_tmp, O_RDWR);
    mmap (...,               PROT_READ | PROT_WRITE | PROT_EXEC, fd);

while allows anonymous RWX mappings:
    mmap (...MAP_ANONYMOUS , PROT_READ | PROT_WRITE | PROT_EXEC, -1);

Thanks to klondike for finding it out.

The result of a horrible typo.

(unreleased yet) upstream also has the patch:

http://github.com/atgreen/libffi/commit/eaf444eabc4c78703c0f98ac0197b1619c1b1bef

dist-install/build/ffi.h should have a dependency on ffitarget.h as *_stub.c requires it during the stage-2 build.

when we think that the libffi build creates them, so they just depend
on the libffi build stamp.