| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Per the usual standards, a build of GHC is only compileable
by the last two releases (e.g. 7.8 only by 7.4 and 7.6). To make sure
we don't get suckered into supporting older compilers, let's remove
this support now.
Signed-off-by: Austin Seipp <austin@well-typed.com>
Test Plan:
Try to bootstrap with GHC 7.4, watch it fail. Bootstrap
with 7.6 or better, and everything works.
Reviewers: hvr
Reviewed By: hvr
Subscribers: simonmar, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D167
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Bug #9439 will cause miscompilation of GHC's LLVM backend. Here we
ensure that an affected compiler isn't used to bootstrap.
Test Plan: Attempt to bootstrap GHC with an affected stage 0 compiler.
Reviewers: rwbarton, austin
Reviewed By: austin
Subscribers: simonmar, relrod, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D159
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This hugs heritage gone away with commit f1dffa0224c9e8dcf1d3908e888e7d683485791b
in 2001
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Test Plan: tried to find HAVE_BIN_SH in internet, no success
Reviewers: simonmar, austin
Reviewed By: austin
Subscribers: phaskell, simonmar, relrod, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D117
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Another macro borrowed from hugs, gone aways in
commit 528a7d2cf1c90408d60028bb1fec85124d539476
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Test Plan: build-tested
Reviewers: simonmar, austin, ezyang
Reviewed By: austin, ezyang
Subscribers: phaskell, simonmar, relrod, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D118
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Both --with-ar and --with-ranlib are usable on non-GNU/Linux systems
where GNU tools are usually installed (or possible to install), but
not into standard location nor with standard name. Tested on Solaris 10.
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>
|
|
|
|
| |
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
| |
|
|
|
|
| |
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Parser.hs needs to be compiled with -fcmm-sink on x86 platforms, so the
register allocator doesn't run out of stack slots. Previously, we had to
do some CPP hacks in order to emit an #ifdef into the file - this is
because we preprocess it once up front, and run the preprocessor again
when we compile it.
There's two cases: the boostrap compiler is > 7.8, and the stage1 parser
needs the flag, or the stage1 compiler is compiling the stage2
Parser.hs, and needs the flag..
The previous approach was super fragile with Clang. The more principled
fix is to instead do this through the build system.
This fixes #8182.
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
I don't think we are using it for anything any more.
|
|
|
|
|
| |
It doesn't look like it would work now, and doesn't really belong in the
GHC tree anyway.
|
|
|
|
| |
We now leave making installers to the Haskell Platform.
|
| |
|
|
|
|
|
| |
Without it, when linking the split objects for Language.Haskell.TH.Syntax,
the commandline was too long when listing all the files directly.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
If anyone wants to do this in the future, they should just set
appropriate CC_OPTS/LD_OPTS variables instead.
|
| |
|
|
|
|
| |
This porting method has bitrotted; use cross-compilation now
|
| |
|
| |
|
|
|
|
|
|
|
| |
It uglifies the code a tiny bit but it's nice to know exactly what
you're using.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
|
|
|
| |
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
version 2.59 seems to be incompatible with our updated macros.
If somebody insists on 2.59 (which is almost 10 years old) I'll
have to hunt down the reason for the recent (Dec 2012?) breakage.
Note that I did not check with 2.60 (I have 2.65), so that one
may still be problematic.
|
|
|
|
| |
document them.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have two cases:
1. building a cross-compiler
2. compiling GHC to run on a foreign platform
These two are done with almost the same setup: (1) is the stage 1
compiler, and (2) is the stage 2 compiler, when CrossCompiling=YES.
The only difference between (1) and (2) is that you if you set up the
build for (1), then it stops before stage 2 and you can 'make install'
to install stage 1.
Unfortunately, (2) didn't work, and the build system code needed some
tidying up.
Change to the way the build is set up:
Before
------
To build a cross-compiler:
./configure --target=<..>
To compile a foreign GHC:
./configure --host=<..> --target=<..>
Now
---
To build a cross-compiler:
./configure --target=<..>
And set "Stage1Only=YES" in mk/build.mk
To compile a foreign GHC:
./configure --target=<..>
|
|
|
|
|
| |
Anything that uses gcc needs to happen after we've made the mingw
inplace tree on Windows.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Based on patch from Peter Trommler:
From 293495d40f62e691520331a41c6d85d82e120169 Mon Sep 17 00:00:00 2001
From: Peter Trommler <ptrommler@acm.org>
Date: Sun, 21 Oct 2012 18:47:01 +0200
Subject: [PATCH] Add configure option to use system provided libffi This
fixes track # 5743 and #4496.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
All supported bootstrapping compilers now have --info output,
so we can use that unconditionally.
|