GitLab

This is a little cleaner, and removes a barrier to cross-compiling
to/from Windows. There are a few more tools that still need to be
handled in the same way.

the former will fail if libbfd is a static library and has a libz
dependency that we don't know about (#3756)

And remove cTargetOS/cTargetPlatform.

Don't check ghc compiles for the right platform when we're bootstrapping.

Makes it consistent with the existing "C compiler flags"
field.

Rather than using the compiler that configure detects, we use
the "GCC command" field from the --info output of the bootstrapping
compiler (provided it is >= 7.1).

We always are, nowadays.

Previously the code generator generated small code fragments labelled
with __stginit_M for each module M, and these performed whatever
initialisation was necessary for that module and recursively invoked
the initialisation functions for imported modules.  This appraoch had
drawbacks:

 - FFI users had to call hs_add_root() to ensure the correct
   initialisation routines were called.  This is a non-standard,
   and ugly, API.

 - unless we were using -split-objs, the __stginit dependencies would
   entail linking the whole transitive closure of modules imported,
   whether they were actually used or not.  In an extreme case (#4387,
   #4417), a module from GHC might be imported for use in Template
   Haskell or an annotation, and that would force the whole of GHC to
   be needlessly linked into the final executable.

So now instead we do our initialisation with C functions marked with
__attribute__((constructor)), which are automatically invoked at
program startup time (or DSO load-time).  The C initialisers are
emitted into the stub.c file.  This means that every time we compile
with -prof or -hpc, we now get a stub file, but thanks to #3687 that
is now invisible to the user.

There are some refactorings in the RTS (particularly for HPC) to
handle the fact that initialisers now get run earlier than they did
before.

The __stginit symbols are still generated, and the hs_add_root()
function still exists (but does nothing), for backwards compatibility.

Using && causes problems on opensolaris, for an unknown reason.
http://www.haskell.org/pipermail/cvs-ghc/2011-March/060314.html

Amongst other improvements, we now handle 3-component versions
(like "3.1.4") correctly.

As we perform some mangling of original --build/--host/--target
params we should check the result of mangling against desired triplet,
not originally passed by user.

Patch also adds mangled triplets to the output.

In a bindist, we generate files like the hsc2hs wrapper.
This means we need to have the right values for the variables like
CONF_GCC_LINKER_OPTS_STAGE1 which in turn means we need to know what
platform we're on.

The use is in install.mk.in, where we need to know when
we're on Cygwin.

This fixes the build on my Windows box, where I have
both Msys and Cygwin.

Patch supplied by the bug reporter, tidied up by me.

$ ./configure --with-ghc=$HOME/fp/bin/i386-unknown-linux/ghc --build=x86_64-unknown-linux
checking for gfind... no
checking for find... /usr/bin/find
checking for sort... /usr/bin/sort
checking for GHC version date... inferred 7.1.20110107
checking version of ghc... 7.0.1
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
Host platform inferred as: i386-unknown-linux
Target platform inferred as: i386-unknown-linux
This GHC (/home/simonmar/fp/bin/i386-unknown-linux/ghc) does not generate code for the build platform
   GHC target platform    : i386-unknown-linux
   Desired build platform : x86_64-unknown-linux

Using Haskell conditionals means the compiler sees all the code, so
there should be less rot of code specific to uncommon arches. Code
for other platforms should still be optimised away, although if we want
to support targetting other arches then we'll need to compile it
for-real anyway.