GitLab

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).

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

It couldn't be overridden, and was defined as YES.

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.

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>

The .hsc files aren't currently safe for cross-compilation on Windows:
    libraries\haskeline\.\System\Console\Haskeline\Backend\Win32.hsc:160
    directive "let" is not safe for cross-compilation

Patch from Brian Bloniarz

Now that we've stopped trying to support 64bit OS X 10.5, the DTrace
problems there don't matter.

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.

There are problems with dtrace on 64bit 10.5. For now at least, we
just turn dtrace off unless you override USE_DTRACE

We no longer use dummy-ghc; instead we don't configure most packages
until the stage1 compiler is available.
  
We also now use Cabal for building the ghc-bin package.

There are a couple more sanity checks too.

The LLVM code generator is always built unconditionally, so both the
configuration variable in mk/config.mk.in as well as the string in
compilerInfo can be removed.

This fixes the "does unsetenv return void" test in the unix package on
OS X, if I tell it to make 10.4-compatible binaries. The test uses
CPPFLAGS but not CFLAGS, so it thought it returned int (as it was
in 10.5-mode), but the C compiler (using CFLAGS, so in 10.4 mode)
thought it returned void.

I also added CONF_LD_OPTS_STAGE$3 to the list of things in LDFLAGS,
which looks like an accidental ommission.

If the GHCi .o lib doesn't exist, load the .a instead

They are no longer right, as we have Haskell' generating new Haskell
standards.

Joseph Jezak reported darcs-2.4.4 SIGSEGV in interactive mode in ghc-6.12.3.
So I've concluded ppc also has rotten native adjustor. I don't have hardware
to verify the patch (ticket #3516 should help to test it), but I think it will
help (as similar patch helped for ia64 and ppc64).

We now use the CONF_CC_OPTS_STAGEn C flags in machdepCCOpts, rather than
repeating them there.