GitLab

We no longer pass -hisuf/-osuf flags to "ghc -M". Doing so didn't really
make sense with the way the -dep-suffix flags now work.

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

We were only setting an RPATH for the RTS DLL on Linux, but as far
as I can see we should be doing it for all ELF OSes. Hopefully this
will fix the problem where the installed ghc-pkg can't find libffi.dll
on FreeBSD.

Spotted by Bill Tutt

Pretty much everything does now, so list those that don't instead
instead of listing those that do.

other than Windows and OS X.

It's known to work on Linux and FreeBSD.

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 now make the stage 2 compiler depend on GHC.Desugar.

It thought that /all/ ways should create the dyn o/hi files, but only
the v way does.

This hasn't been used for some time

Technically we don't need the v way, but with -dynamic-too it's cheap,
and having it makes life easier.

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.

We were finding vanilla object files when TH needed dynamic object files.

It doesn't work yet

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