Ben Gamari authored 2 years ago and Marge Bot committed 2 years ago

Here we at long last remove the `make`-based build system, it having
been replaced with the Shake-based Hadrian build system. Users are
encouraged to refer to the documentation in `hadrian/doc` and this [1]
blog post for details on using Hadrian.

Closes #17527.

[1] https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html

John Ericson authored 3 years ago and Marge Bot committed 3 years ago

This allows us to clean up the rts include dirs in the package conf.

John Ericson authored 3 years ago and Marge Bot committed 3 years ago

This is the following find and replace:

 - `rts/dist` -> `rts/dist-install` # for paths
 - `rts_dist` -> `rts_dist-install` # for make rules and vars
 - `,dist` -> `,dist-install` # for make, just in rts/ghc.mk`

Why do this? Does it matter when the RTS is just built once? The answer
is, yes, I think it does, because I want the distdir--stage
correspondence to be consistent.

In particular, for #17191 and continuing from
d5de970d I am going to make the headers
(`rts/includes`) increasingly the responsibility of the RTS (hence their
new location). However, those headers are current made for multiple
stages. This will probably become unnecessary as work on #17191
progresses and the compiler proper becomes more of a freestanding cabal
package (e.g. a library that can be downloaded from Hackage and built
without any autoconf). However, until that is finished, we have will
transitional period where the RTS and headers need to agree on dirs for
multiple stages.

I know the make build system is going away, but it's not going yet, so I
need to change it to unblock things :).

Peter Trommler authored 3 years ago and Marge Bot committed 3 years ago

Update submodule libffi-tarballs to upstream commit 4f9e20a.

Remove C compiler flags that suppress warnings in the RTS. Those
warnings have been fixed by libffi upstream.

Fixes #19885

Takenobu Tani authored 5 years ago and Marge Bot committed 5 years ago

This moves all URL references to Trac Wiki to their corresponding
GitLab counterparts.

This substitution is classified as follows:

1. Automated substitution using sed with Ben's mapping rule [1]
    Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...
    New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...

2. Manual substitution for URLs containing `#` index
    Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz
    New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz

3. Manual substitution for strings starting with `Commentary`
    Old: Commentary/XxxYyy...
    New: commentary/xxx-yyy...

See also !539

[1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json

Summary:
building libffi docs with our intree-libffi seems
rather pointless.

Reviewers: bgamari, austin

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

Moritz Angermann authored 7 years ago and Ben Gamari committed 7 years ago

This is rather annoying. I'd prefer to have a stable release to
use. However libffi-3.2.1 has been released November 12, 2014, and
libffi-4 is TBD. See also https://github.com/libffi/libffi/issues/296

The core reason for this change is that llvm changed the supported
assembly to unified syntax, which libffi-3.2.1 does not use, and hence
fails to compile for arm with llvm. For refence, see the following
issue: https://github.com/libffi/libffi/issues/191.

This diff contains a script to generate a tarball for the
`libffi-tarballs` repository from the libffi GitHub repository; as well
as the necessary changes to the build system.

Updates libffi-tarballs submodule.

Reviewers: austin, bgamari, hvr

Subscribers: hvr, erikd, rwbarton, thomie

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

This reverts commit 8d4bce42.

This is rather annoying. I'd prefer to have a stable release to
use. However libffi-3.2.1 has been released November 12, 2014, and
libffi-4 is TBD. See also https://github.com/libffi/libffi/issues/296

The core reason for this change is that llvm changed the supported
assembly to unified syntax, which libffi-3.2.1 does not use, and hence
fails to compile for arm with llvm. For refence, see the following
issue: https://github.com/libffi/libffi/issues/191

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, snowleopard

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

Reviewers: bgamari, austin

Subscribers: thomie

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

GHC Trac Issues: #10238

Using `:` as sed-`s`-expr separator is not a good idea on windows, as
this can result in an expression like

   's:@INSTALL@:$(subst ../install-sh,E:/msys64/home/foo/ghc/install-sh,@INSTALL@):g'

(note the `E:/` drive component)

Using `|` instead of `:` has less risk of collision with the substitution expression

Herbert Valerio Riedel authored 9 years ago and Ben Gamari committed 9 years ago

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #11109

We only support building GHC on mys2 nowadays, see
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows.

This (partially) reverts various commits from a few years ago, among which:
  * 5775d514
    "Add OSTYPE build-system variable, and use it"
  * 3fb8c431
    "Fix building libgmp on cygwin"
  * cdbb4720
    "Fix cmd invocation by libffi cuild system on Windows 7 cygwin"
  * e8121501
    "Fix dblatex and xml* tool detection on Windows"

Reviewed by: austin, Phyx

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

Got detected by gentoo's QA preinstall hook:
 * RWX --- --- usr/lib/ghc-7.10.1/rts/libffi.so.6.0.2
 * RWX --- --- usr/lib/ghc-7.10.1/rts/libffi.so
 * RWX --- --- usr/lib/ghc-7.10.1/rts/libffi.so.6
 * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi.a:win32.o
 * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_p.a:win32.o
 * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_l.a:win32.o
 * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_debug.a:win32.o
 * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_thr.a:win32.o
 * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_thr_debug.a:win32.o
 * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_thr_l.a:win32.o
 * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_thr_p.a:win32.o

Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Test Plan: built ghc-7.10.1 binary and checked stacks as NX

Reviewers: rwbarton, hvr, austin

Reviewed By: austin

Subscribers: thomie

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

GHC Trac Issues: #10208

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

This should address #9924 as GHC's config.guess/sub versions need to be
up to date anyway.

Reviewers: austin

Reviewed By: austin

Subscribers: thomie, carter, ezyang, simonmar

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

GHC Trac Issues: #9720

On some systems (depending on gcc multilib configuration) libffi
would install into libffi/build/inst/lib64 even though we configure
it with --libdir=libffi/build/inst/lib. There appears to be no way
to get libffi to install to a predictable directory "out of the box",
so we apply a small patch to Makefile.in. This is the same fix used
in Gentoo's ebuild (https://bugs.gentoo.org/show_bug.cgi?id=462814).

This means that ghc-tarballs is only needed on Windows

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.

This fixes a bug with how configure re-execs itself.

On Windows, we need to keep the DLL called libffi-6.dll (rather than
libffi.dll) or Windows can't find it.

Fixes the build on platforms that default to using a directory called
lib64. Reported by Gabriel Dos Reis.

Patchset from Stephen Blackheath <stephen.blackheath@ipwnstudios.com>

* Pass -Irts/dist/build to the C preprocessor to expose libffi headers (ffi.h and ffitarget.h) to foreign import wrappers during the building process of GHC itself.
* Install libffi headers into $(ghcheaderdir) just like any other C headers. Otherwise an installed GHC can't find them when it wants to compile foreign import wrappers.
* Include libffi headers in the bindist for the same reason.

With Windows 7 in a vitrual box VM on OS X, some very odd things happen
with dates and time stamps when SSHing into cygwin. e.g. here the
"Change" time is in the past:

$ date; touch foo; stat foo
Fri Dec  2 16:58:07 GMTST 2011
  File: `foo'
  Size: 0               Blocks: 0          IO Block: 65536  regular
empty file
Device: 540aba0bh/1409989131d   Inode: 562949953592977  Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/     ian)   Gid: (  513/    None)
Access: 2011-12-02 16:58:07.414457900 +0000
Modify: 2011-12-02 16:58:07.414457900 +0000
Change: 2011-12-02 16:58:03.495141800 +0000
 Birth: 2011-12-02 16:57:57.731469900 +0000

And if we copy such a file, then the copy is older (as determined by the
"Modify" time) than the original:

$ date; touch foo; stat foo; cp foo bar; stat bar
Fri Dec  2 16:59:10 GMTST 2011
  File: `foo'
  Size: 0               Blocks: 0          IO Block: 65536  regular
empty file
Device: 540aba0bh/1409989131d   Inode: 1407374883725128  Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/     ian)   Gid: (  513/    None)
Access: 2011-12-02 16:59:10.118457900 +0000
Modify: 2011-12-02 16:59:10.118457900 +0000
Change: 2011-12-02 16:59:06.189477700 +0000
 Birth: 2011-12-02 16:57:57.731469900 +0000
  File: `bar'
  Size: 0               Blocks: 0          IO Block: 65536  regular
empty file
Device: 540aba0bh/1409989131d   Inode: 281474976882512  Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/     ian)   Gid: (  513/    None)
Access: 2011-12-02 16:59:06.394555800 +0000
Modify: 2011-12-02 16:59:06.394555800 +0000
Change: 2011-12-02 16:59:06.395532400 +0000
 Birth: 2011-12-02 16:58:40.921899600 +0000

This means that make thinks that things are out of date when it
shouldn't, so reinvokes itself repeatedly until the MAKE_RESTARTS
infinite-recursion test triggers.

The touchy program, like most other programs, creates files with both
Modify and Change in the past, which is still a little odd, but is
consistent, so doesn't break make.

We avoid calling "rm -rf" with no file arguments; this fixes cleaning
on Solaris, where that fails.

We also check for suspicious arguments: anything containing "..",
starting "/", or containing a "*" (you need to call $(wildcard ...)
yourself now if you really want globbing). This should make things
a little safer.

iWe were adding c:/... to $PATH, but : is the separator
in $PATH.

We now put the libffi objects into the RTS library, rather than trying
to mangle libffi into being a ghc package itself. It would be nicer to
 make it a separate library (but not a ghc package), but for now
 hopefully this will get the build going through on Windows again.