GitLab

We used to say 10.3, but this gives
    -rpath can only be used when targeting Mac OS X 10.5 or later 
when building shared libraries.
Patch from mwotton.

- We have -m32 as machine-dependent option for gcc for a 32 bit build
- Like on OpenBSD, SL requires -fno-stack-protector to avoid triggering the
  stack smashing checks inserted by gcc by default on this platform.

This avoids a collision between the directories we use when compiling
multiple ways, which in turn leads to a race condition in parallel
builds.

Patch from
    Max Bolingbroke <batterseapower@hotmail.com>
Rerecorded to avoid conflicts.

Previously it only did it for binaries. This was presumably on the
theory that the binary could specify the rpath for all the libs.
However when it is the shared lib that is the final product (ie to
link into a bigger project) then we need the rpaths for the shared
lib to be self-contianed.

It's still possible to override it, just use -optl-Wl,-soname, eg:
ghc -shared -dynamic foo.o -o libfoo.so -optl-Wl,-soname,libbar.so

Previously the object code for the C main function lived in the rts
lib, however this is a problem when the rts is built as a shared lib.
With Windows DLLs it always causes problems while on ELF systems it's a
problem when the user decides to use their own C main function rather
than a Haskell Main.main. So instead we now put main in it's own tiny
little static lib libHSrtsmain.a which we install next to the rts libs.
Whenever ghc links a program (without -no-hs-main) then it also links
in -lHSrtsmain. For consistency we always do it this way now rather
than trying to do it differently for static vs shared libraries.

We now do it for all ways and for all platforms. This was a Windows-only
version that only kept a separate Main.dyn_o for the dynamic linking case.
It had to do that because Windows DLLs are stricter about unresolved symbols
where as for ELF platforms we only run into the problem when we're not using
a Haskell main function.

Also remove some unused cruft

By default, gcc on OS X will generate SSE instructions, which need
things 16-byte aligned, but we don't 16-byte align things. Thus drop
back to generic i686 compatibility.

Fixes trac #2872.

They still need to be stored in IORefs, as the exception handler needs
to know what they all are.

With this change it should be possible to perform something similar to
'load' by traversing the module graph in dependency order and calling
'{parse,typecheck,load}Module' on each.  Of course, if you want smart
recompilation checking you should still use 'load'.

parameter to 'InteractiveStatus' to a 'Maybe'.

This patch entails a major restructuring of HscMain and a small bugfix
to MkIface (which required the restructuring in HscMain).

In MkIface:

  - mkIface* no longer outputs orphan warnings directly and also no
    longer quits GHC when -Werror is set.  Instead, errors are
    reported using the common IO (Messages, Maybe result) scheme.

In HscMain:

  - Get rid of the 'Comp' monad.  This monad was mostly GhcMonad + two
    reader arguments, a ModSummary for the currently compiled module
    and a possible old interface.  The latter actually lead to a small
    space-leak since only its hash was needed (to check whether the
    newly-generated interface file was the same as the original one).

    Functions originally of type 'Comp' now only take the arguments
    that they actually need.  This leads to slighly longer argument
    lists in some places, however, it is now much easier to see what
    is actually going on.

  - Get rid of 'myParseModule'.  Rename 'parseFile' to 'hscParse'.

  - Join 'deSugarModule' and 'hscDesugar' (keeping the latter).

  - Rename 'typecheck{Rename}Module{'}' to 'hscTypecheck{Rename}'.
    One variant keeps the renamed syntax, the other doesn't.

  - Parameterise 'HscStatus', so that 'InteractiveStatus' is just a
    different parameterisation of 'HscStatus'.

  - 'hscCompile{OneShot,Batch,Nothing,Interactive}' are now
    implemented using a (local) typeclass called 'HsCompiler'.  The
    idea is to make the common structure more obvious.  Using this
    typeclass we now have two functions 'genericHscCompile' (original
    'hscCompiler') and 'genericHscRecompile' (original 'genComp')
    describing the default pipeline.  The methods of the typeclass
    describe a sort of "hook" interface (in OO-terms this would be
    called the "template method" pattern).

    One problem with this approach is that we parameterise over the
    /result/ type which, in fact, is not actually different for
    "nothing" and "batch" mode.  To avoid functional dependencies or
    associated types, we use type tags to make them artificially
    different and parameterise the type class over the result type.
    A perhaps better approach might be to use records instead.
    
  - Drop some redundant 'HscEnv' arguments.  These were likely
    different from what 'getSession' would return because during
    compilation we temporarily set the module's DynFlags as well as a
    few other fields.  We now use the 'withTempSession' combinator to
    temporarily change the 'HscEnv' and automatically restore the
    original session after the enclosed action has returned (even in
    case of exceptions).

  - Rename 'hscCompile' to 'hscGenHardCode' (since that is what it
    does).

Calls in 'GHC' and 'DriverPipeline' accordingly needed small
adaptions.

It now uses the standard warning log and error reporting mechanism.

Parse errors during dependency analysis or options parsing really
shouldn't kill GHC; this is particularly annoying for GHC API clients.

The sense of the #ifdef was wrong

Do not filter the rts from linked libraries in linkDynLib as Windows does not allow unresolved symbols

When linking in --make we check the modification time of the
executable against the modification time of the object files, and only
re-link if any object file is newer.  However, we should also check
the modification times of packages, since the recompilation checker
also tracks dependencies in packages.  

In a GHC build this means that if you recompile stage2 and don't
manage to change any fingerpints, we won't recompile Main but we'll
still re-link it.

Now that we don't include any header files in .hc apart from our own,
the cc-options from packages are at best superfluous, so don't pass
them.

We still pass them to .c compilations, although I've just made changes
to Cabal so that cc-options from a .cabal file are not copied into the
InstalledPackageInfo.  Most uses of cc-options in Cabal are clearly
intended to be local to the package, but they were being propagated
everywhere, almost certainly unintentionally.

The way is left open for Cabal to allow packages to specify cc-options
that get propagated in the future, if we find a use case for this.

TopHandler now uses the new extensible exceptions module, so we
need to interact with it using the new types.

We want to be able to pick the RTS flavour (e.g. -threaded) when we
link the final program.

These are needed for GLOBAL_VAR's to work properly