| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Requires some ghc-cabal changes as well.
Test Plan: ./validate
Reviewers: hvr, bgamari
Reviewed By: bgamari
Subscribers: hsyl20, erikd, alpmestan, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4453
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
ld.gold is buggy when using -r and a linker script. See upstream bug
https://sourceware.org/bugzilla/show_bug.cgi?id=22266
This has been causing various brokenness for the GHC runtime linker,
where we load these broken object files.
Test Plan: Test program from #14675
Reviewers: bgamari, RyanGlScott, alpmestan, hvr, erikd
Subscribers: rwbarton, thomie, erikd, carter
GHC Trac Issues: #14328, #14675, #14291
Differential Revision: https://phabricator.haskell.org/D4431
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By request of @alexbiehl.
CCing @snowleopard and @alpmestan as the same should be done in Hadrian.
Bumps haddock submodule.
Reviewers: alexbiehl
Reviewed By: alexbiehl
Subscribers: rwbarton, thomie, carter, snowleopard, alpmestan, alexbiehl
Differential Revision: https://phabricator.haskell.org/D4365
|
|
|
|
|
| |
Do not use $SHELL as $SHELL is the user's preferred interactive shell.
We do not want this to leak into the wrapper scripts.
|
|
|
|
|
|
| |
This isn't needed anymore as we don't support GHC < 8 anymore.
This is a follow-up to 122f183
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This tool can be used to generate dll's for any list of object files
given to it. It will then repartition them automatically to fit within
a dll and generates as many dll's as needed to do this. Cyclic dependencies
between these generated dlls are handle automatically so there is no need
to tell it how to partition.
It is also a lot more general than `dll-split` as it is able to split any
package not just `libGHC`. It also uses a trick using GNU style import libraries
to hide the splitting from the rest of the pipeline. Which means come linking time
you don't need to know which dll contains what symbol or how many split dlls were
created.
The import libraries are by default created with libtool. However since libtool is BFD
based it is very slow. So if present and detected by configure the `genlib` tool
from the msys2 project is used. This makes a difference of about ~45 minutes when compiling.
To install `genlib` run `pacman -Sy mingw-w64-$(uname -m)-tools-git`.
More detailed explaination of the process can be found here
https://ghc.haskell.org/trac/ghc/wiki/WindowsDynamicLinking
Test Plan: ./validate
Reviewers: austin, hvr, bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: snowleopard, rwbarton, thomie, erikd, #ghc_windows_task_force
GHC Trac Issues: #5987
Differential Revision: https://phabricator.haskell.org/D3883
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes dll-split from the code base, the reason is dll-split
no longer makes any sense. It was designed to split a dll in two, but we
now already have many more symbols than would fit inside two dlls. So we
need a third one. This means there's no point in having to maintain this
list as it'll never work anyway and the solution isn't scalable.
Test Plan: ./validate
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie, #ghc_windows_task_force
GHC Trac Issues: #5987
Differential Revision: https://phabricator.haskell.org/D3882
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cabal's parser has been rewritten in terms of Parsec (which is not
enabled yet in Cabal-2.0 by default, but can be enabled by a cabal
flag). The plan for Cabal is to drop support for the non-parsec parser,
so we need to prepare GHC to cope with new situation.
However, this means that lib:Cabal requires three new library
dependency submodules,
- parsec
- text
- mtl
What complicates matters is that we need to build `ghc-cabal` early on
during the bootstrap phase which currently needs to invoke `ghc --make`
directly. So these additional dependencies need to be integrated into
the monolithic `ghc --make` invocation which produces the `ghc-cabal`
executable.
Test Plan: `./validate --fast` passed
Reviewers: austin, bgamari
Subscribers: erikd, phadej, rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3757
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Initial implementation of split-section on Windows.
This also corrects section namings and uses the platform
convention of `$` instead of `.` to separate sections.
Implementation is based on @awson's patches to binutils.
Binutils requires some extra help when compiling the libraries
for GHCi usage. We drop the `-T` and use implicit scripts to amend
the linker scripts instead of replacing it.
Because of these very large GHCi object files, we need big-obj support,
which will be added by another patch.
Test Plan: ./validate
Reviewers: awson, austin, bgamari
Subscribers: dfeuer, rwbarton, thomie, snowleopard, #ghc_windows_task_force
GHC Trac Issues: #12913
Differential Revision: https://phabricator.haskell.org/D3383
|
|
|
|
|
|
|
|
|
|
|
| |
terminfo no longer needs to be able to find the ncurses headers.
See https://github.com/judah/terminfo/pull/22.
Reviewers: austin, hvr
Subscribers: rwbarton, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D3688
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the regressions in the haddock performance tests introduced
in c9eb4385aad248118650725b7b699bb97ee21c0d.
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie
GHC Trac Issues: #13789
Differential Revision: https://phabricator.haskell.org/D3629
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes it's handy to change a compiler flag
for a library in stage{0,1,2}.
Usage example:
libraries/binary_EXTRA_HC_OPTS += -O1
libraries/containers_EXTRA_HC_OPTS += -O1
libraries/bytestring_EXTRA_HC_OPTS += -O1
Here override default -O2 defined in .cabal files
for these libraries to speed build up.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The build failure when cross-compiling from
linux to windows looks like:
HC [stage 1] ghc/stage2/build/tmp/ghc-stage2.exe
Call hs_init_ghc() from your main() function to set these options.
/usr/libexec/gcc/i686-w64-mingw32/ld: cannot find -lHSghc-8.3-0
Similar to commit 745032dd02da511067c2939259ed212852187e0f
("rts: tweak cross-compilation to mingw32") decision to split
stage2 should be done based based on TargetOS, not HostOS.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the introduction of -split-sections, using GHCi with the RTS
linker is really slow:
```
$ time (echo :quit | ./inplace/bin/ghc-stage2 --interactive -fexternal-interpreter)
GHCi, version 8.1.20170304: http://www.haskell.org/ghc/ :? for help
Prelude> Leaving GHCi.
real 0m3.793s
```
(when we use `-fexternal-interpreter` it uses the RTS linker by default,
you can make it use the system linker by adding `-dynamic`)
Building the GHCi libs doesn't take much time or space in the GHC build,
but makes things much quicker for people using the RTS linker:
```
$ time (echo :quit | ./inplace/bin/ghc-stage2 --interactive -fexternal-interpreter)
GHCi, version 8.1.20170304: http://www.haskell.org/ghc/ :? for help
Prelude> Leaving GHCi.
real 0m0.285s
```
So I propose that we build and ship them unconditionally.
Test Plan: validate, perf tests above
Reviewers: bgamari, austin, niteria, erikd, Phyx
Reviewed By: bgamari
Subscribers: rwbarton, thomie, snowleopard
Differential Revision: https://phabricator.haskell.org/D3298
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After commit a50082c11 we use -ffunction-sections -fdata-sections
for all C compilations, when $1_$2_SplitSections is set. But that
variable was set in build-package.mk which is not run for the RTS.
As a result the RTS was not being split, leading to larger binaries.
This commit fixes RTS splitting by moving the definition of
$1_$2_SplitSections to distdir-opts.mk, which is run for the RTS
(and also from build-package.mk).
Test Plan:
manual ./validate and check that RTS and base .c files
are split, but not object files in the compiler
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie, snowleopard, olsner
Differential Revision: https://phabricator.haskell.org/D3137
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously this was added only to the RTS's C files (those are the bulk
of it though), but there are C bits in ghc-prim, integer-gmp and base
too.
Followup for #8405, allows the large table of character properties in
base to be stripped when not used.
Test Plan: validate
Reviewers: austin, bgamari, simonmar
Reviewed By: bgamari
Subscribers: thomie, snowleopard
Differential Revision: https://phabricator.haskell.org/D3121
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By default ghc-pkg is quite noisy as it can't find interface files.
Test Plan:
Look at the build log stderr and see if there are lots of "cannot find
any of" errors.
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie, snowleopard
Differential Revision: https://phabricator.haskell.org/D3103
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is two types of options passed directly to 'ld'
(and not to 'gcc' driver):
- CONF_LD_LINKER_OPTS_STAGE$4
- EXTRA_LD_OPTS
This changedoes two things:
- split 'EXTRA_LD_OPTS' into two variables:
- EXTRA_LD_OPTS (accepts 'gcc' wrapper options)
- EXTRA_LD_LINKER_OPTS (accepts raw 'ld' options)
- wraps all LD_LINKER options as '-Wl,' when passed
to 'gcc' driver.
Fixes https://phabricator.haskell.org/D2776
Signed-off-by: Sergei Trofimovich <siarheit@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts f48f5a9ebf384e1e157b7b413e1d779f4289ddd2
The prefixing does not work as comma
is stripped by $(addprefix) macro:
The following call
$$(addprefix -optl-Wl, $$($1_$2_$3_ALL_LD_OPTS))
prefixes options with "-optl-Wl" not with "-optl-Wl,"
The simplest breakage can be seen by adding
SRC_LD_OPTS += -O1
to mk/build.mk:
<no location info>: error:
Warning: Couldn't figure out linker information!
Make sure you're using GNU ld, GNU gold
or the built in OS X linker, etc.
gcc: error: unrecognized command line option '-Wl-O1'
Another problem with original change is loss of ability
to pass options to gcc as a linker driver, for example:
SRC_LD_OPTS += -flto
Signed-off-by: Sergei Trofimovich <siarheit@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC uses gcc, not ld, for linking. Consequently all flags to be
interpreted by ld need to be prefixed by -optl,-Wl on the GHC command
line.
Test Plan: Validate on OpenBSD
Reviewers: austin, rwbarton
Reviewed By: rwbarton
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2776
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: GHC CI
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: snowleopard, thomie
Maniphest Tasks: T74
Differential Revision: https://phabricator.haskell.org/D2732
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This ensures that artifacts built with build-prog see these options.
Also spruce up comments.
Test Plan: Carefully read it.
Reviewers: austin, hvr, erikd
Reviewed By: erikd
Subscribers: thomie, erikd
Differential Revision: https://phabricator.haskell.org/D2673
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This omits -L and -l flags from the linker command line that shouldn't
be necessary because GHC will already add them via the -package-id
flags we pass.
This also reverts part of 90538d86af579595987826cd893828d6f379f35a
that rearranges the linker command line and causes some knock-on
problems (see D2618).
Test Plan: validate (need to validate on Windows too)
Reviewers: Phyx, bgamari, niteria, austin, erikd
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2639
GHC Trac Issues: #12738
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously this was a relative path which worked in the GHC tree, but
failed elsewhere. This caused trouble for out-of-tree users as well as
Hadrian, which wants to move build artifacts out of the working
directory. Fixes #8040.
Test Plan: Validate
Reviewers: thomie, austin, snowleopard, hvr
Reviewed By: snowleopard, hvr
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2530
GHC Trac Issues: #8040
|
|
|
|
| |
This avoids the interactive prompt of xelatex on error.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically per-component macros and multiple libraries.
Contains Cabal submodule update.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: austin, bgamari
Reviewed By: austin, bgamari
Subscribers: hvr, thomie
Differential Revision: https://phabricator.haskell.org/D2059
|
|
|
|
| |
The madness that is latex never ceases to amaze.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously programs only depended upon the direct dependencies; while I
would have thought that this would be sufficient, somehow we were
getting to the link step of building `ghc-pkg` before `ghc-boot-th` was
built (despite the fact that `ghc-boot` has a direct dependency on
`ghc-boot-th`).
See #12078.
|
|
|
|
| |
There was a missing `#`. Hadrian couldn't come soon enough.
|
|
|
|
|
| |
This may have been the cause of various build failures on FreeBSD and
Solaris.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Previously the `_static` and `_sources` directories were installed in
the wrong parents. See #11803
|
|
|
|
|
|
|
| |
This was introduced in 109a1e53287f50103e8a5b592275940b6e3dbb53
but isn't needed anymore because by now we're bootstrapping with
GHC versions which already provide "ld command" in `ghc --info`
(that field was added in GHC 7.8)
|
|
|
|
| |
This allows building ghc in '/ghc'.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A small cosmetic change, but we have to do a bit of work to
actually support it:
- Cabal submodule update, so that Cabal passes us
-this-unit-id when we ask for it. This includes
a Cabal renaming to be consistent with Unit ID, which
makes ghc-pkg a bit more scrutable.
- Build system is updated to use -this-unit-id rather than
-this-package-key, to avoid deprecation warnings. Needs
a version test so I resurrected the old test we had
(sorry rwbarton!)
- I've *undeprecated* -package-name, so that we are in the same
state as GHC 7.10, since the "correct" flag will have only
entered circulation in GHC 8.0.
- I removed -package-key. Since we didn't deprecate -package-id
I think this should not cause any problems for users; they
can just change their code to use -package-id.
- The package database is indexed by UNIT IDs, not component IDs.
I updated the naming here.
- I dropped the signatures field from ExposedModule; nothing
was using it, and instantiatedWith from the package database
field.
- ghc-pkg was updated to use unit ID nomenclature, I removed
the -package-key flags but I decided not to add any new flags
for now.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: austin, hvr, bgamari
Reviewed By: bgamari
Subscribers: 23Skidoo, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D1780
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Build then clean
Reviewers: austin, thomie
Reviewed By: thomie
Differential Revision: https://phabricator.haskell.org/D1786
GHC Trac Issues: #11433
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The main goal here is enable stack traces in GHCi. After this change,
if you start GHCi like this:
ghci -fexternal-interpreter -prof
(which requires packages to be built for profiling, but not GHC
itself) then the interpreter manages cost-centre stacks during
execution and can produce a stack trace on request. Call locations
are available for all interpreted code, and any compiled code that was
built with the `-fprof-auto` familiy of flags.
There are a couple of ways to get a stack trace:
* `error`/`undefined` automatically get one attached
* `Debug.Trace.traceStack` can be used anywhere, and prints the current
stack
Because the interpreter is running in a separate process, only the
interpreted code is running in profiled mode and the compiler itself
isn't slowed down by profiling.
The GHCi debugger still doesn't work with -fexternal-interpreter,
although this patch gets it a step closer. Most of the functionality
of breakpoints is implemented, but the runtime value introspection is
still not supported.
Along the way I also did some refactoring and added type arguments to
the various remote pointer types in `GHCi.RemotePtr`, so there's
better type safety and documentation in the bridge code between GHC
and ghc-iserv.
Test Plan: validate
Reviewers: bgamari, ezyang, austin, hvr, goldfire, erikd
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1747
GHC Trac Issues: #11047, #11100
|
|
|
|
|
|
| |
This code was introduced in 66218d15b7c27a4a38992003bd761f60bae84b1f to
use `-package-name` for GHC 7.8, whereas GHC 7.10 needs the new
`-this-package-key` flag.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to simplify the task, the version munging logic has
been radically simplified:
Previously, in cases where the version contained dates as version components,
the build-system would munge the version of the stage1 ghc package before
registering the `ghc` package.
However, this hack was already questionable at the time of its introduction
(c.f. 7b45c46cbabe1288ea87bd9b94c57e010ed17e60).
Simplifying the build-systems by avoiding such hacks may also help the
shaking-up-ghc effort.
So now we simply munge directly via the `.cabal` files, which gives a simpler
picture, as now every stage is munged the same. Munging is only active when
the first patch-level version component is a date. So stable snapshots and release
candidates are unaffacted (as those have the date in the second patch-level
version component)
Reviewers: simonmar, bgamari, austin, thomie, ezyang
Reviewed By: bgamari, thomie, ezyang
Differential Revision: https://phabricator.haskell.org/D1673
|
|
|
|
|
|
|
|
|
| |
This follows a similar change in
4905b83a2d448c65ccced385343d4e8124548a3b, where binaries are installed
in libexecdir/bin instead of libexecdir.
This fixes a problem with ghc not able to find ghc-split, when
SplitObjs=YES.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allowing one to pass the new `--hyperlinked-source` option to generate
pretty marked-up sources for the core libraries.
Test Plan: Try it
Reviewers: hvr, austin
Reviewed By: austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1643
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
(Apologies for the size of this patch, I couldn't make a smaller one
that was validate-clean and also made sense independently)
(Some of this code is derived from GHCJS.)
This commit adds support for running interpreted code (for GHCi and
TemplateHaskell) in a separate process. The functionality is
experimental, so for now it is off by default and enabled by the flag
-fexternal-interpreter.
Reaosns we want this:
* compiling Template Haskell code with -prof does not require
building the code without -prof first
* when GHC itself is profiled, it can interpret unprofiled code, and
the same applies to dynamic linking. We would no longer need to
force -dynamic-too with TemplateHaskell, and we can load ordinary
objects into a dynamically-linked GHCi (and vice versa).
* An unprofiled GHCi can load and run profiled code, which means it
can use the stack-trace functionality provided by profiling without
taking the performance hit on the compiler that profiling would
entail.
Amongst other things; see
https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details.
Notes on the implementation are in Note [Remote GHCi] in the new
module compiler/ghci/GHCi.hs. It probably needs more documenting,
feel free to suggest things I could elaborate on.
Things that are not currently implemented for -fexternal-interpreter:
* The GHCi debugger
* :set prog, :set args in GHCi
* `recover` in Template Haskell
* Redirecting stdin/stdout for the external process
These are all doable, I just wanted to get to a working validate-clean
patch first.
I also haven't done any benchmarking yet. I expect there to be slight hit
to link times for byte code and some penalty due to having to
serialize/deserialize TH syntax, but I don't expect it to be a serious
problem. There's also lots of low-hanging fruit in the byte code
generator/linker that we could exploit to speed things up.
Test Plan:
* validate
* I've run parts of the test suite with
EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th.
There are a few failures due to the things not currently implemented
(see above).
Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1562
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to fcc6b1d / D1608 which is made possible
by the recent Cabal update:
As `ghc-cabal` is called with `--with-gcc`, this gets passed to `./configure`
as `CC=...` argument. So we don't need to set `CC=...` ourselves explicitly again.
Prior to the changes in Cabal (pulled in via 0bf0cf936c7) and fcc6b1d,
`./configure` scripts would be called with a `--with-cc` argument followed by a
`--with-gcc` argument.
After this commit, `./configure` will be passed a single `CC=...` argument
constructed by the `Cabal` library.
Reviewed By: erikd
Differential Revision: https://phabricator.haskell.org/D1611
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The non-idiomatic `--with-cc` flag was added via
5c789e424c1461c1dadfd38c44fcb9e8f38bf755
However, `--with-cc` seems rather fragile and support for `--with-cc` needs
to be added explicitly to autoconf-based Cabal packages. The `CC=` flag, however,
is supported natively by GNU Autoconf, so let's use the standard facility for that.
Relatedly, Cabal prior to version 1.24 used a similiar flag `--with-gcc=...`,
but starting with Cabal-1.24 this has been changed to use `CC=...` instead as well
(see https://github.com/haskell/cabal/pull/2946)
This also updates a few submodules removing the now obsolete `--with-cc` flag
support.
Reviewed By: trofi, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D1608
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The INSTALL_PROGRAM variable is set in mk/config.mk, so we have to
include that file before using it.
Running 'make install' before './configure' in a bindist will now also
display a nice message.
Reviewers: hvr, austin, bgamari
Reviewed By: bgamari
Differential Revision: https://phabricator.haskell.org/D1604
GHC Trac Issues: #1851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add stage specific versions of SRC_HC_OPTS. These are currently only
used for -Werror. The previous combination of GhcStage2HcOpts and
GhcLibHcOpts didn't apply to utils/*.
* Add stage specific versions of SRC_HC_WARNING_OPTS. These will later be
used for new warning supression flags that should not be passed to the
bootstrap compiler.
* Move -Wall (and -Werror) related code back to mk/warnings.mk, where it
was before 987d54274. Now all warning related code is nicely together.
Include mk/warnings.mk after mk/custom-settings.mk to make this work.
Reviewed By: bgamari, hvr
Differential Revision: https://phabricator.haskell.org/D1536
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Only use the merge_sections.ld linker script if SplitSections is enabled.
I thought I had a way to make the linker script actually work on Windows
and produce object files instead of image files (by using the "INSERT AFTER"
linker script command to get the default script's output format setting),
but that fix caused ghci to crash with an illegal instruction on startup.
Gave up and made a simpler fix of just disabling this for normal builds,
as it's only really relevant with SplitSections enabled anyway.
Reviewers: austin, thomie, bgamari
Reviewed By: austin, thomie
Subscribers: Phyx, thomie
Differential Revision: https://phabricator.haskell.org/D1505
GHC Trac Issues: #8405
|
|
|
|
|
|
|
|
| |
This works around Mac OS X's sed, which doesn't support \+.
For the record,
The regex implementation in Mac OS X 10.8 and later is based on a heavily
modified subset of TRE, http://laurikari.net/tre/
|