GitLab

I think overall the new approach is simpler. Rather than unpacking
the libffi.a and putting the .o files into our libHSrts.a, we just
use the libffi.a.

This change also means that when compiling programs for the dyn
way, they get explicitly linked against libffi.so (rather than
relying on librts.so being linked against it). This might
fix a problem on FreeBSD, where programs cannot find libffi.so.

There's no point splitting objects when we're going to be dynamically
linking. Plus it breaks compilation on OSX x86.

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

LLVM supports PIC on ARM from what I can see.
Signed-off-by: Austin Seipp <aseipp@pobox.com>

We were previously enabling Opt_PIC on certain OSes namely Windows,
Darwin and Linux, but it should always be enabled for the dyn way
because it makes no sense to try to generate non-PIC dynamic
libraries, which is usually impossible.

On OpenBSD and NetBSD, we were accidentally passing "-optl-pthread" to
the gcc to build dynamic libraries because of a bitrotted hack for
those OSes, which resulted in a weird situation where every dynamic
library is named "ptl-pthread" and placed at "$(TOP)".

The hack in question were to work around a linkage problem with
libHSffi, but we no longer build it and just use libffi these days so
the hack can safely be removed.

There were some cases where we weren't unsetting it when turning the
Dyn way on.

v2: added a couple of comments

In particular, this means that GHCi will use DLLs, rather than loading
object files itself.

This is a slightly refined version of a patch by shachaf,
done by Krzysztof Gogolewski <krz.gogolewski@gmail.com>.

I'm not sure why it caused problems before, but it's fine now.

We now run the tail of the pipeline twice, rather than trying to
do both ways in lockstep.

The goal is that the second subphase will be run twice when using
-dynamic-too

Patch from Stephen Blackheath!

It would probably still benefit from some tidying up, but it's now
much more opaque, with the control flow easier to understand.

We don't need them, but GHC API users might.

Doesn't look like it causes any failures in the full test suite, so
presumably it's fine!

It's now only used once

pipeLoop now returns the final dflags, rather than having
runPipeline' extract it from the end state.

This fixes certain older GCCs which do not accept link options when assembling or compiling:

  ppc_85xx-gcc: --hash-size=31: linker input file unused because linking not done
  ppc_85xx-gcc: --reduce-memory-overheads: linker input file unused because linking not done

and diagnose this to stderr.

We only use the unicode characters if the locale supports them.