Erik de Castro Lopo authored 10 years ago and thoughtpolice committed 10 years ago

Fixes #8976 and #9873 by making use of the Binutils ld.gold
linker explicit whenever the target is linux/ARM or android/ARM.
This does not affect iOS where Apple provides its own linker.

In order to achieve this, we need to add `-fuse-ld=gold` to
the SettingsCCompilerLinkFlags setting and set
SettingsLdCommand to `ld.gold` (or `${target}-ld.gold` when
cross-compiling). In addition, simplifying the use of
`$(CONF_GCC_LINKER_OPTS_STAGEn)`.

This patch was tested by ensuring that the following worked
as expected:

  * Native builds on linux/x86_64 (nothing changed).
  * Native builds on linux/arm (and uses the gold linker).
  * Linux to linux/arm cross compiles (and uses the cross
    gold linker).

Contributions by Ben Gamari, Joachim Breitner and Reid Barton.

Reviewers: nomeata, bgamari, austin, rwbarton

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D715

GHC Trac Issues: #8976 #9873

(cherry picked from commit 71fcc4c0)

PHO authored 10 years ago and thoughtpolice committed 10 years ago

Summary:
If curses is installed into some non-standard path, we currently have
to say something like the following in mk/build.mk:

  libraries/terminfo_CONFIGURE_OPTS += \
      --configure-option=--with-curses-includes=/somewhere/include \
      --configure-option=--with-curses-libraries=/somewhere/lib

This is because the top-level configure does not accept nor propagate
--with-curses-{includes,libraries} to libraries while it does so for
iconv, gmp and libffi. It would be nice if curses were handled in the
same manner.

Test Plan: Install curses into some non-standard path. Then run the top-level "configure" script with options "--with-curses-includes=/path/to/curses/include" and "--with-curses-libraries=/path/to/curses/lib".

Reviewers: austin

Reviewed By: austin

Subscribers: thomie, PHO

Differential Revision: https://phabricator.haskell.org/D665

GHC Trac Issues: #10096

(cherry picked from commit bbb57a6b)

tuncer authored 10 years ago and Herbert Valerio Riedel committed 10 years ago

(cherry picked from commit 0fa42402)

Don't pass empty string `[]` as "action-if-not-given" to `AC_ARG_ENABLE()`
macro, as this would otherwise lead to an empty else-block in the resulting
bash `configure` script. This bug was introduced via cb0a503a.

This issue was pointed out by @christiaanb

Reviewed By: christiaanb

Differential Revision: https://phabricator.haskell.org/D545

Since we switched to a Git submodule based GHC Git repo, `ghc.git`'s
commit id uniquely identifies the state of the GHC source-tree. So
having that information embedded into the `ghc` executable provides
valuable information to track accurately (especially when created by
buildbots) from which source-tree-state a given `ghc` snapshot
(distribution) was generated.

So this commit adds a new field `"Project Git commit id"` to the
`ghc --info` meta-data containing the `./configure`-time Git commit id
as reported by `git rev-parse HEAD`.

This field can also be queried with `ghc --print-project-git-commit-id`.

For source distributions, the file `GIT_COMMIT_ID` is created (with some
sanity checking to detect stale commit ids, as that would render this
information rather useless)

Reviewed By: austin

Differential Revision: https://phabricator.haskell.org/D528

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Summary:
Patch does the following:
- fixes detection of working libbfd on modern linux
  platforms (where bfd_uncompress_section_contents is a macro)
- disables 'bfd' by default and adds '--enable-bfd-debug'
  configure option. As bfd's ABI is unstable
  the feature is primarily useful by ghc hackers.

Not done (subject for another patch):
- one-time bfd object memory leak in DEBUG_LoadSymbols
- in '-dynamic' mode debugging symbols are loaded only for
  current executable, not all libraries it is linked against.

Fixes Issue #8790

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

Test Plan: built unregisterised ghc on amd64 and ran './hello +RTS -Di' there

Reviewers: simonmar, austin

Reviewed By: simonmar, austin

Subscribers: thomie, simonmar, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D193

GHC Trac Issues: #8790

This exposes the `cProjectPatchLevel{1,2}` value at the CPP level to
allow it to be used in CPP conditionals. Concretely, GHC 7.10.2.20150623
would result in

  #define __GLASGOW_HASKELL__             710
  #define __GLASGOW_HASKELL_PATCHLEVEL1__ 2
  #define __GLASGOW_HASKELL_PATCHLEVEL2__ 20150623

while GHC 7.10.3 results in

  #define __GLASGOW_HASKELL__             710
  #define __GLASGOW_HASKELL_PATCHLEVEL1__ 3

and finally GHC 7.9.20141009 results in

  #define __GLASGOW_HASKELL__             709
  #define __GLASGOW_HASKELL_PATCHLEVEL1__ 20141009

As it's error-prone to properly express CPP conditionals for testing GHC
multi-component versions, a new macro `MIN_VERSION_GLASGOW_HASKELL()` is
provided (also via the new CPP include file `ghcversion.h`)

Finally, in order to make it easier to define the new CPP macro
`MIN_VERSION_GLASGOW_HASKELL()`, a new default-included
`include/ghcversion.h` is used for the new CPP definitions.

Reviewed By: ekmett, austin, #ghc

Differential Revision: https://phabricator.haskell.org/D66

Summary:
"./configure --target=TARGET" was broken; it would use the host gcc.
(So you had to explicitly specify "--with-gcc=TARGET-gcc" also,
as a workaround.)

This was broken by commit fc4856f9
for #8148. A comment claimed that FP_ARG_WITH_PATH_GNU_PROG_OPTIONAL
was the same as FP_ARG_WITH_PATH_GNU_PROG except for not raising
an error when the program isn't found; but that wasn't true --
the former didn't prepend the target name when cross-compiling.

We actually need three versions of FP_ARG_WITH_PATH_GNU_PROG since
the LLVM tools are usually not prefixed with the target name even
when cross-compiling. So I generalized the logic in a single macro.

Test Plan:
Built with "./configure --target=i386-unknown-linux"
and BuildFlavour=quick, successfully

Reviewers: ezyang, austin

Reviewed By: ezyang, austin

Subscribers: simonmar, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D204

Summary:
This includes pretty much all the changes needed to make `Applicative`
a superclass of `Monad` finally. There's mostly reshuffling in the
interests of avoid orphans and boot files, but luckily we can resolve
all of them, pretty much. The only catch was that
Alternative/MonadPlus also had to go into Prelude to avoid this.

As a result, we must update the hsc2hs and haddock submodules.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Test Plan: Build things, they might not explode horribly.

Reviewers: hvr, simonmar

Subscribers: simonmar

Differential Revision: https://phabricator.haskell.org/D13

Summary:
LLVM llc and opt commands should be set on all platforms, including
Windows. If they're not, GHC tries to execute an unnamed executable,
resulting in error messages such as:

    Error (figuring out LLVM version): : runInteractiveProcess: invalid argument (Invalid argument)
    <no location info>:
        Warning: Couldn't figure out LLVM version!
                 Make sure you have installed LLVM

This regression was introduced in e6bfc596.

Test Plan: Build GHC and test if --info shows sensible values of "LLVM llc command" and "LLVM opt command"

Reviewers: austin, #ghc

Reviewed By: austin, #ghc

Subscribers: austin

Projects: #ghc

Differential Revision: https://phabricator.haskell.org/D190

GHC Trac Issues: #7143

It turned out the sed(1) expressions are not fully portable.  So revist my
earlier attempt for getting GHC_LDFLAGS in the configure script and rewrite
it in Perl instead.

Summary:
Solaris 11 distributed GNU C 4.5.x is configured in a way that its
CPP is not working well while invoked from GHC. GHC runs it with
-x assembler-with-cpp and in this particular configuration GNU C CPP
does not provide any line-markers so GHC's output of errors or warnings
is confusing since it points to preprocessed file in /tmp and not
to the original Haskell file. Fortunately old GNU C 3.4.x is still
provided by the OS and when installed it'll be used automatically
as GHC CPP which is whole logic of this patch. So although we use modern
GCC as a C compiler and assembler we use old GCC as a C preprocessor.

Test Plan: validate

Reviewers: austin

Reviewed By: austin

Subscribers: phaskell, simonmar, relrod, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D151

Fixes #9363.

Signed-off-by: Austin Seipp <austin@well-typed.com>

The recent version of ghc-prim assumes a more modern processor as it
exploits built-in atomic operations, and some of them are not yet
present on i486.  Hence the -march flag is explicitly set to i686 for the
C compiler -- just to be in sync with the default of other distributions.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Summary:
this set of patches adds support for x86_64-solaris2 platform
Solaris is multi-lib platform which means it provides 32bit user-land together
with 32bit and 64bit libraries. The 32bit libraries are located in <somewhere>/lib
directories while 64bit libraries are located in <somewhere>/lib/64 directories.
This is why GHCi required the fix since otherwise it'll attempt to load
/usr/lib/libgmp.so which is 32bit library into 64bit binary process space (GHCi).
This of course fails with wrong ELFCLASS32 error message.
Another issue was that by default GNU C distributed with Solaris compiles
into 32bit binary. We need to enforce compilation to 64bit binary
by adding appropriate -m64 option.

Test Plan: already built on x86_64-solaris2

Reviewers: austin

Reviewed By: austin

Subscribers: phaskell, simonmar, relrod, carter

Differential Revision: https://phabricator.haskell.org/D68

Signed-off-by: Austin Seipp <austin@well-typed.com>

Summary:
Allow the CPP program and flag choices for GHC
be configured via the the ghc settings file

Test Plan: ran validate yesterday

Reviewers: hvr, austin, mzero, simonmar

Reviewed By: austin, mzero, simonmar

Subscribers: mzero, simonmar, relrod, carter

Differential Revision: https://phabricator.haskell.org/D26

Signed-off-by: Austin Seipp <austin@well-typed.com>

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>

krakrjak authored 11 years ago and Krzysztof Gogolewski committed 11 years ago

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.