GitLab

With gcc 4.4 we get
    Error: can't resolve `.note.GNU-stack' {.note.GNU-stack section} - `.Ltext0' {.text section}
when running gcc with the -g flag. To work around this we unset
CFLAGS when running the test.

It used to make the build work on cygwin, but now it breaks it instead:
    config.status: creating include/Makefile
    gawk: ./confLqjohp/subs.awk:1: BEGIN {\r
    gawk: ./confLqjohp/subs.awk:1: ^ backslash not last character on line
    config.status: error: could not create include/Makefile
    make[2]: *** [libffi/stamp.ffi.configure-shared] Error 1
    make[1]: *** [all] Error 2

Fixes a build failure on OS X 10.6. When linking
    rts/dist/build/libHSrts-ghc6.13.20100519.dylib
we got
    ld: symbol dyld_stub_binding_helper not defined (usually in crt1.o/dylib1.o/bundle1.o)
    collect2: ld returned 1 exit status

Later packages are supposed to shadow earlier ones in the stack,
unless the ordering is overriden with -package-id flags.
Unfortunately an earlier fix for something else had sorted the list of
packages so that it was in lexicographic order by installedPackageId,
and sadly our test (cabal/shadow) didn't pick this up because the
lexicographic ordering happened to work for the test.  I've now fixed
the test so it tries both orderings.

We now tell it where to find ld, nm and ar

This will hopefully fix #2889.

1. allow multiple threads to call startTimer()/stopTimer() pairs
2. disable the timer around fork() in forkProcess()

A corresponding change to the process package is required.

Spotted by Marco Túlio Gontijo e Silva

We still need the workaround for when compiling HEAD with 6.12.2

The libtool creates "libffi.dylib" and "libffi.5.dylib" but not "libffi.5.0.9.dylib". Having it in libffi_DYNAMIC_LIBS causes an infinite makefile loop. 

I had incorrectly "optimised" checkHiBootIface so that it forgot
to update the "knot-tied" type environment. 

This patch fixes the HEAD

  
As well as fixing #4019, I rejigged the way that Ord instances are
generated, which should make them faster in general.  See the 
Note [Generating Ord instances].

I tried to measure the performance difference from this change, but
the #4019 fix only removes one conditional branch per iteration, and
I couldn't measure a consistent improvement.  But still, tihs is
better than before.

We eta-expand things with INLINE pragmas; 
see Note [Eta-expanding INLINE things].

But I eta-expanded it the wrong amount when the function
was overloaded.  Ooops.

When using the bootstrapping compiler, we now explicitly constrain
the version of boot packages (Cabal, extensible-exceptions, etc) to the
in-tree version, so that the build system is less fragile should the
user have a newer version installed for the bootstrapping compiler.

This fixes a problem when building with GHC 6.12 on Windows, where
dependencies on stage 0 (bootstrapping compiler) packages have absolute
paths c:/ghc/..., and make gets confused by the colon.

It now understand the ghc-stage[123] names we use in-tree, and it won't
go looking for any old ghc-pkg if it can't find the one that matches
ghc.

Broken by "Split part of the Task struct into a separate struct
InCall".

Default currently NO.

Validate passed with GhcDynamic=YES on x86/Linux here.

The compiler is currently slower on x86 when linked -dynamic,
because the GC inner loop has been adversely affected by -fPIC, I'm
looking into how to fix it.

When GHCi is linked dynamically, we still want to be able to load
non-dynamic object files.