| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
|
| |
|
|
|
|
|
|
| |
Our special ghc-cabal command needs to be told that we are building with
dynamic library support when it does its copying. We do so by passing an
extra parameter from ghc.mk.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sdist preps the tree via distclean before anything else, which caused
HsTimeConfig.h.in under 'time' to be deleted - even though it should be
included in the resulting tarball for ./configure.
The correct target is 'maintainer-clean'.
I'm guessing the nightlies didn't complain because they run ./boot,
forcing regeneration. NixOS's Hydra does not, though.
Thanks to Peter Simons and Andres Löh for pointing this out.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
|
|
|
|
|
|
|
|
| |
ghctags needs the stage2 compiler, since it uses the GHC API.
Fixes #8126.
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.
|
|
|
|
| |
Part of #7833
|
| |
|
|
|
|
| |
I don't think we are using it for anything any more.
|
| |
|
|
|
|
| |
We now check in the same way that the testsuite does.
|
|
|
|
|
| |
It doesn't look like it would work now, and doesn't really belong in the
GHC tree anyway.
|
| |
|
|
|
|
| |
Fixes #7592.
|
|
|
|
|
| |
Now that we can build the GHC package the dyn way, there's no need
to exclude them.
|
|
|
|
|
|
| |
It now consistently takes directory and distDirectory as its first 2
arguments. Also, it only supports configuring 1 package at a time now
(we weren't using the ability to configure more than one at once).
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Dynamic GHC is now working in-place, but pathologically slow due
to the DLL split.
(GHC assumes that all intra-package calls are in the same DLL, but that
isn't true when we split the GHC package into 2 DLLs. That means that
GHC's startup time is around 22 seconds, as it is doing run-time
linking).
Also, ghci isn't actually working yet:
$ inplace/bin/ghc-stage2 --interactive
GHCi, version 7.7.20130512: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... <command line>: can't load .so/.DLL for:
HSghc-prim-0.3.1.0.dll (addDLL: could not load DLL)
ghc-stage2.exe: HSghc-prim-0.3.1.0: The specified module could not be
found.
|
| |
| |
| |
| | |
Not just base, integer-gmp and ghc-prim.
|
|/ |
|
|
|
|
|
|
|
|
|
| |
This is a rather ugly hack to fix dynamically linked GHC on Windows.
If GHC is linked with -threaded, then it links against libHSrts_thr.
But if base is linked against libHSrts, then both end up getting
loaded, and things go wrong. We therefore link the libraries that
link against the RTS with the same RTS flags that we link GHC with.
|
|
|
|
|
| |
I don't think these should be necessary. If something breaks as
a result then we can look at why.
|
| |
|
|
|
|
| |
We weren't seting the _DO_HADDOCK variables early enough.
|
|
|
|
| |
I don't think it's necessary to build ghc-pkg that early.
|
|
|
|
|
|
| |
Dependency problem was discovered by int-e.
I've also added some comments about what's going on.
|
|
|
|
| |
Also a couple of other fixes and sanity checks along the way.
|
|
|
|
| |
We now leave making installers to the Haskell Platform.
|
| |
|
| |
|
| |
|
|
|
|
| |
The file no longer exists
|
|
|
|
|
|
| |
The build system thought that $(INSTALL_DYNLIBS) contained things
like "terminfo", but actually it contains things like
"libraries/terminfo".
|
|\ |
|
| | |
|
|/ |
|
|
|
|
|
| |
In particular, this means that GHCi will use DLLs, rather than loading
object files itself.
|
| |
|
|
|
|
|
|
| |
We now put a handful of modules in a separate DLL.
For now the list is hand-written, but we could automate it in the
future.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Patch from Stephen Blackheath.
|
|
|
|
|
|
|
|
| |
This is sometimes needed when cross-compiling, as some packages may be
built in stage 0 but not stage 1.
In order to make everything work out, this also removes the requirement
that the build-dirs are in dependency order
|
| |
|
| |
|
| |
|
| |
|