GitLab

This is ArchUnknown for now, as it requires some porting work over and
above powerpc64 due to such things as the different function calling
sequence in the ELFv2 ABI.  For now, an unregisterised port is better
than nothing.
Signed-off-by: Colin Watson <cjwatson@debian.org>
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>

Haddock no longer has a generated parser, so we don't need it in the
sdist and we certainly don't want to check for it in the ./configure
script (as that would be bogus.)
Signed-off-by: Austin Seipp <austin@well-typed.com>

Version of Happy required is now 1.19.

In 6579a6c7 we removed existing comparison primops and introduced new ones
returning Int# instead of Bool. This commit (and associated commits in
array, base, dph, ghc-prim, integer-gmp, integer-simple, primitive, testsuite and
template-haskell) restores old names of primops. This allows us to keep
our API cleaner at the price of not having backwards compatibility.

This patch also temporalily disables fix for #8317 (optimization of
tagToEnum# at Core level). We need to fix #8326 first, otherwise
our primops code will be very slow.

This is temporary until new bool primops have been pushed.

* This partially fixes #8148. However, --with-ghc-4.8 will still not work given the rather dubious m4 macros and the failures in the test suite due to '-nodefaultlibs' still need to be fixed.

iOS has some particular constraints about how applications can be built:

 * We must generate a static library (.a) since XCode does the final
   link.
 * We need to carefully give the right set of arguments to libtool in
   the case we're generating an archive.
 * Dynamic linking isn't supported.
 * It can only be done on OS X.

This patch cleans up all of the above. We add a new flag `-staticlib`
(only supported on Darwin) that allows us to produce archive files using
libtool, and a -pgmlibtool flag to control which 'libtool' executable to
use.

This fixes #8127. I believe this is the last piece missing from the iOS
cross compiler.
Authored-by: Luke Iannini <lukexi@me.com>
Authored-by: Maxwell Swadling <maxwellswadling@gmail.com>
Authored-by: Stephen Blackheath <...@blacksapphire.com>
Signed-off-by: Austin Seipp <aseipp@pobox.com>

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

The iOS simulator is essentially an iOS target but for an x86 machine
instead. It doesn't support the native code generator either, though.
Authored-by: Stephen Blackheath <...@blacksapphire.com>
Signed-off-by: Austin Seipp <aseipp@pobox.com>

When cross compiling to iOS, we generate archive files which are linked
into the final executable. We already *did* generate archive files -
just with the wrong suffix.

Fixes #8125.
Authored-by: Stephen Blackheath <...@blacksapphire.com>
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.

Patch from singpolyma.

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>

If we can't find a better date to use, then use today's date.

Affects i386 only. Some gcc's generate code containing __i686, and then
define that symbol to 1, which causes compilation to fail. We undef
the symbol to work around it.

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

Signed-off-by: David Waern <david.waern@gmail.com>

[ ] is m4 syntax, so we need to use 'test foo' rather than '[ foo ]'.

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.

The loop exit condition was testing ${LLC} instead of $1, which was
incorrect. While I'm here, quote the path being tested since it may contain
spaces (e.g. on Windows), and don't search paths that don't exist, which
eliminates un-useful error messages from find.

approach. This way can handle spaces in paths.

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

Patch modified from one by Karel Gardas <karel.gardas@centrum.cz>.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>