| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than using the non-standard/idiomatic `--with-{gcc,clang}=...`
scheme use the `CC=...` style scheme.
The basic idea is to have Autoconf's CC/CFLAG/CPPFLAG apply to
stage{1,2,3}, while having a separate _STAGE0 set of env-vars
denote the bootstrap-toolchain flags/programs.
This should be simpler, less confusing, and somewhat more in line with
Autoconf's idioms (allowing us to reuse more of Autoconf rather than
(re)inventing our own confusing non-standard m4 macros to do stuff that
Autoconf could almost do already for us)
Morever, expose CC_STAGE0 as a so-called "precious" variable.
So now we can better control which bootstrapping gcc is used
(by default the one used by the stage0 ghc, unless CC_STAGE0 is
overriden)
```
Some influential environment variables:
CC_STAGE0 C compiler command (bootstrap)
CC C compiler command
CFLAGS C compiler flags
...
Use these variables to override the choices made by `configure' or to
help it to find libraries and programs with nonstandard names/locations.
```
Test Plan: I've tested that cross-compiling with
`--target=powerpc-linux-gnu` still works, and tried a few variants of
settting `CC=` and `CC_STAGE0=`; `./validate` passed as well
Reviewers: erikd, austin, bgamari, simonmar
Reviewed By: simonmar
Subscribers: Phyx, thomie
Differential Revision: https://phabricator.haskell.org/D2078
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Try configure in an environment with older `libdw`
Reviewers: hvr, austin
Subscribers: thomie, erikd
Differential Revision: https://phabricator.haskell.org/D2103
GHC Trac Issues: #11820
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first phase of addressing #11757 which aims to make C99
support a base-line requirement for GHC and clean up the code-base to
use C99 facilities when sensible.
This patch exploits the logic/heuristic used by `AC_PROG_CC_C99` to
determine the flags needed in case the C compiler isn't able to compile
C99 code in its current mode. We can't use `AC_PROG_CC_C99` directly
though because GHC's build-system expects CC to contain a filename
without any flags, while `AC_PROG_CC_C99` would e.g. result in
`CC="gcc -std=gnu99"`. Morever, we support different `CC`s for
stage0/1/2, so we need a version of `AC_PROG_CC_C99` for which we can
specify the `CC`/`CFLAGS` variables to operate on. This is what
`FP_SET_CFLAGS_C99` does.
Note that Clang has been defaulting to C99+ for a long time, while GCC 5
defaults to C99+ as well. So this has mostly an affect on older GCCs
versions prior to 5.0 and possibly compilers other than GCC/Clang (which
are not officially supported for building GHC anyway).
Reviewers: kgardas, erikd, bgamari, austin
Reviewed By: erikd
Differential Revision: https://phabricator.haskell.org/D2045
|
|
|
|
| |
Fixes #11419
|
|
|
|
| |
Fixes #11419.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some parts of the build system require that paths are what msys2 calls
"mixed style":
* forwards slashes
* absolute paths starting with a drive letter followed by a colon
(e.g. "C:")
The removal of ghc-pwd in 4c56ad3 changed $(TOP) from mixed style to
unix style, resulting in a broken Windows build for some.
Differential Revision: https://phabricator.haskell.org/D1752
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows, with msys2, `pwd` works (as can be seen by the use of `pwd`
that slipped into the validate script), so there is really no need for
`ghc-pwd` anymore.
Test Plan: try it
Reviewers: austin, bgamari, Phyx
Reviewed By: Phyx
Subscribers: Phyx, erikd
Differential Revision: https://phabricator.haskell.org/D1731
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds basic support to the RTS for DWARF-assisted unwinding of the
Haskell and C stack via libdw. This only adds the infrastructure;
consumers of this functionality will be introduced in future diffs.
Currently we are carrying the initial register collection code in
Libdw.c but this will eventually make its way upstream to libdw.
Test Plan: See future patches
Reviewers: Tarrasch, scpmw, austin, simonmar
Reviewed By: austin, simonmar
Subscribers: simonmar, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D1196
GHC Trac Issues: #10656
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* distrib/configure.ac.in : Detect correct version of LLVM tools as
was done for the top level configure.ac in 42448e3757.
* aclocal.m4 : Add a FIND_LD macro that can be used in both
configure scripts.
* Use new FIND_LD macro in both configure scripts.
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
Test Plan: validate on amd64-linux and armhf-linux.
Reviewers: rwbarton, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D828
GHC Trac Issues: #10234
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: carter, austin
Reviewed By: austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D648
GHC Trac Issues: #9094
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
```
git grep -l '#!' | xargs sed -i 's|#!.*/bin/\([^ ]*\)$|#!/usr/bin/env \1|'
```
and some manual tweaking
Test Plan: harbormaster
Reviewers: austin
Subscribers: hvr, simonmar, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D237
GHC Trac Issues: #9057
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Haskell2010 implies (at least) EmptyDataDecls, ForeignFunctionInterface,
PatternGuards, DoAndIfThenElse, and RelaxedPolyRec.
This is a follow-up to dd92e2179e3171a0630834b773c08d416101980d
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
|
|
|
|
| |
As suggested in #9057.
|
| |
|
|
|
|
|
|
| |
(fixes #8794)
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
It now just warns about files it doesn't recognise, rather than giving
an error. This means that random text files etc in the same directory
as the bindists don't make it fall over.
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
| |
Makes it clearer whether it succeeded when redirecting output
|
|
|
|
|
| |
It thought that something impossible was happening when they
were involved.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This program:
main :: IO ()
main = do re "[^ ]" "\207"
re "[ ]" "\207"
re " " "\207"
re :: String -> String -> IO ()
re r str = let r' = makeRegex r :: Regex
res = matchM r' str :: Maybe (String, String, String, [String])
in print res
prints
Nothing
Nothing
Nothing
for me with Posix, but
Just ("","\207","",[])
Nothing
Nothing
with PCRE. This was causing compare to fail with
Tar line doesn't parse: "drwxrwxr-x simonmar/GHC 0 2012-12-08 21:35 ghc-7.6.1.20121207/libraries/haskeline/tests/dummy-\206\188\206\177\207\\302\\203/"
on the GHC source tarball.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
They are no longer used
|
|
|
|
|
| |
We no longer produce installers fo OS X; we leave that to the Haskell
Platform team.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This required various build system changes to get the build to go
through.
In the inplace shell wrappers, we set LD_LIBRARY_PATH to allow programs
to find their libraries. In the future, we might change the inplace tree
to be the same shape as an installed tree instead. However, this would
mean changing the way we do installation, as currently we use cabal's
installation methods to install the libraries, but that only works if
the libraries are under libraries/foo/dist-install/build/..., rather
than in inplace/lib/...
|
|
|
|
|
| |
Now that it's included in settings, the bindist configure script needs
to know it.
|
| |
|
|
|
|
| |
Related to #4862
|
| |
|
| |
|
|
|
|
|
| |
Cabal no longer has a userguide that we know how to build, so we
can't include it in our docs.
|
|
|
|
|
|
| |
Maybe we could revisit whether we want to allow building bindists of
cross-compilers later, but for now I'm fixing validate by setting all
the cross-compilation settings to NO.
|
|
|
|
|
| |
We want to use the inplace ar, rather than whichever ar the
machine that we build on happens to have.
|
|
|
|
|
|
|
| |
On XCode 4.1, we use /usr/bin/gcc-4.2 as it makes better code than
/usr/bin/gcc for us. However, gcc-4.2 doesn't exist in XCode 4.2, so we
need to use /usr/bin/gcc there. As the installer can be used on either,
we make it always use /usr/bin/gcc.
|
|
|
|
|
| |
Now target32bit works for all targets without any manual intervention,
as it should do. #5735 was a portability regression.
|
|
|
|
|
| |
Some platforms use linkers that don't support the --hash-size=31 and
--reduce-memory-overheads flags.
|
| |
|
| |
|
| |
|