Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Parser.hs needs to be compiled with -fcmm-sink on x86 platforms, so the
register allocator doesn't run out of stack slots. Previously, we had to
do some CPP hacks in order to emit an #ifdef into the file - this is
because we preprocess it once up front, and run the preprocessor again
when we compile it.

There's two cases: the boostrap compiler is > 7.8, and the stage1 parser
needs the flag, or the stage1 compiler is compiling the stage2
Parser.hs, and needs the flag..

The previous approach was super fragile with Clang. The more principled
fix is to instead do this through the build system.

This fixes #8182.

Signed-off-by: Austin Seipp <aseipp@pobox.com>

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.

Previously, we did ./configure time checks to see if 'GNU ld' supported
certain options. If it does, we bake those options into the link step.
See Trac #5240.

Unfortunately, the linker we use at runtime can change for several
reasons. One is that the user specifies -pgml 'foo'. The other is if
/usr/bin/ld or whatnot changes from when GHC was built.  Those options
mentioned earlier are specific to GNU ld, but many systems support GNU
gold too. This is Trac #6063.

So we need to check at runtime what linker we're using. This is actually
a little bit complicated because we normally use the C compiler as our
linker. Windows and OS X are also special here.

Finally, this patch also unconditionally gives '--hash-size=31' and
'--reduce-memory-overheads' to the system linker if it's GNU ld. These
options have been supported for 8+ years from what I can see, and there
are probably a lot of other reasons why GHC would not work with such an
ancient binutils, all things considered.

See Note [Run-time linker info] in SysTools for details. There are
plenty of comments as well in the surrounding code.

Signed-off-by: Austin Seipp <aseipp@pobox.com>

I don't think we are using it for anything any more.

It doesn't look like it would work now, and doesn't really belong in the
GHC tree anyway.

We now leave making installers to the Haskell Platform.

Without it, when linking the split objects for Language.Haskell.TH.Syntax,
the commandline was too long when listing all the files directly.

If anyone wants to do this in the future, they should just set
appropriate CC_OPTS/LD_OPTS variables instead.

This porting method has bitrotted; use cross-compilation now

It uglifies the code a tiny bit but it's nice to know exactly what
you're using.

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

version 2.59 seems to be incompatible with our updated macros.
If somebody insists on 2.59 (which is almost 10 years old) I'll
have to hunt down the reason for the recent (Dec 2012?) breakage.

Note that I did not check with 2.60 (I have 2.65), so that one
may still be problematic.

document them.

We have two cases:
 1. building a cross-compiler
 2. compiling GHC to run on a foreign platform

These two are done with almost the same setup: (1) is the stage 1
compiler, and (2) is the stage 2 compiler, when CrossCompiling=YES.

The only difference between (1) and (2) is that you if you set up the
build for (1), then it stops before stage 2 and you can 'make install'
to install stage 1.

Unfortunately, (2) didn't work, and the build system code needed some
tidying up.

Change to the way the build is set up:

Before
------

To build a cross-compiler:
  ./configure --target=<..>

To compile a foreign GHC:
  ./configure --host=<..> --target=<..>

Now
---

To build a cross-compiler:
  ./configure --target=<..>
  And set "Stage1Only=YES" in mk/build.mk

To compile a foreign GHC:
  ./configure --target=<..>

Anything that uses gcc needs to happen after we've made the mingw
inplace tree on Windows.

Anything that uses gcc needs to happen after we've made the mingw
inplace tree on Windows.

Based on patch from Peter Trommler:

    From 293495d40f62e691520331a41c6d85d82e120169 Mon Sep 17 00:00:00 2001
    From: Peter Trommler <ptrommler@acm.org>
    Date: Sun, 21 Oct 2012 18:47:01 +0200
    Subject: [PATCH] Add configure option to use system provided libffi This
     fixes track # 5743 and #4496.

All supported bootstrapping compilers now have --info output,
so we can use that unconditionally.

We no longer actually use ITIMER_VIRTUAL anyway