| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
| |
To correctly perform a linking hack for Windows we need to link with the
RTS GHC is currently using. We used to query the RTS ways via the
"settings" file but it is fragile (#18651). The hack hasn't been fixed
to take into account all the ways (Tracing) and it makes linking of GHC
with another RTS more difficult (we need to link with another RTS and to
regenerate the settings file).
So this patch uses the ways reported by the RTS itself
(GHC.Platform.Ways.hostWays) instead of the "settings" file.
|
| |
|
|
|
|
|
|
| |
As noted in #18726, this regularly breaks. Let's test it.
Note that we don't actually perform a build of GHC itself; we merely
test that the Hadrian executable builds and works (by invoking `hadrian
--version`).
|
| | |
|
| | |
|
| |
|
|
| |
Fixes #18800.
|
| | |
|
| |
|
|
| |
Necessary for recent Win32 bump.
|
| | |
|
| |
|
|
|
| |
GHC now requires happy-1.20, which isn't available in LTS-16.14.
Fixes #18726.
|
| |
|
|
|
|
| |
Specifically the "Inline literal start-string without end-string"
warning, which typically means that the user neglected to separate
an inline code block from suffix text with a backslash.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
"ghci" as a flag name was confusing because it really enables the
internal-interpreter. Even the ghci library had a "ghci" flag...
|
| |
|
|
|
|
|
| |
Doing so causes the name of the test environment to gain an extra
set of double quotes, which changes the name entirely.
Fixes #18656.
|
| |
|
|
|
|
| |
Strangely I find that on Alpine (and apparently only on Alpine) the
latex makeindex command expects to be given a filename, lest it reads
from stdin.
|
| | |
|
| |
|
|
|
|
|
| |
Otherwise the input hash will vary with whether colors are requested,
which changed with `isatty`.
Fixes #18672.
|
| |
|
|
|
|
| |
Previously hadrian would use GHC on PATH when configuring packages (or
fail if there is no such GHC). Fix this. Unfortunately this runs into
another bug in Cabal which we workaround.
|
| |
|
|
|
|
|
| |
We now generate our Docker images via Dhall definitions, as described in
ghc/ci-images!52. Additionally, we are far more careful about where tools
come from, using the ALEX, HAPPY, HSCOLOR, and GHC environment variables
(set in the Dockerfiles) to find bootstrapping tools.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In b592bd98ff25730bbe3c13d6f62a427df8c78e28 we started using
-dead_strip_dylib on macOS when lining dynamic libraries and binaries.
The underlying reason being the Load Command Size Limit in macOS
Sierra (10.14) and later.
GHC will produce @rpath/libHS... dependency entries together with a
corresponding RPATH entry pointing to the location of the libHS...
library. Thus for every library we produce two Load Commands. One to
specify the dependent library, and one with the path where to find it.
This makes relocating libraries and binaries easier, as we just need to
update the RPATH entry with the install_name_tool. The dynamic linker
will then subsitute each @rpath with the RPATH entries it finds in the
libraries load commands or the environement, when looking up @rpath
relative libraries.
-dead_strip_dylibs intructs the linker to drop unused libraries. This in
turn help us reduce the number of referenced libraries, and subsequently
the size of the load commands. This however does not remove the RPATH
entries. Subsequently we can end up (in extreme cases) with only a
single @rpath/libHS... entry, but 100s or more RPATH entries in the Load
Commands.
This patch rectifies this (slighly unorthodox) by passing *no* -rpath
arguments to the linker at link time, but -headerpad 8000. The
headerpad argument is in hexadecimal and the maxium 32k of the load
command size. This tells the linker to pad the load command section
enough for us to inject the RPATHs later. We then proceed to link the
library or binary with -dead_strip_dylibs, and *after* the linking
inspect the library to find the left over (non-dead-stripped)
dependencies (using otool). We find the corresponding RPATHs for each
@rpath relative dependency, and inject them into the library or binary
using the install_name_tool. Thus achieving a deadstripped dylib (and
rpaths) build product.
We can not do this in GHC, without starting to reimplement a dynamic
linker as we do not know which symbols and subsequently libraries are
necessary.
Commissioned-by: Mercury Technologies, Inc. (mercury.com)
|
| |
|
|
|
| |
Only the debugging page contains interesting stuff. Some of this stuff
looks old (e.g. recommending "cabal install")...
|
| |
|
|
|
|
|
| |
The fix to #17962 ended up regressing on Windows as it failed to
replicate the logic responsible for overriding the toolchain paths on
Windows. This resulted in a hard-coded path to a directory that likely
doesn't exist on the user's system (#18550).
|
| |
|
|
|
|
|
|
| |
This patch adds the upper bound of a happy version for ghc-9.2.
Currently, We can use happy-1.19 or happy-1.20 for ghc-9.2.
See #18620.
|
| |
|
|
|
|
|
|
|
| |
This patch adds the upper bound of a happy version for ghc-9.0
and earlier.
Currently, we can't use happy-1.20.0 for ghc-9.0.
See #18620.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
As noted in #18560, we previously would always run the LLVM ways since
`configure` would set `SettingsLlcCommand` to something non-null when
it otherwise couldn't find the `llc` executable. Now we rather probe for
the existence of the `llc` executable in the testsuite driver.
Fixes #18560.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Previously to merge a set of object files we would invoke the linker as
usual, adding -r to the command-line. However, this can result in
non-sensical command-lines which causes lld to balk (#17962).
To avoid this we introduce a new tool setting into GHC, -pgmlm, which is
the linker which we use to merge object files.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the invocation of `cabal configure`, `--ghc-pkg-option=--global-package-db`
was already given correctly to tell `stage0/bin/ghc-pkg` that it should use
the package DB in `stage1/`.
However, `ghc` needs to be given this information as well, not only `ghc-pkg`!
Until now that was not the case; the package DB in `stage0` was given to
`ghc` instead.
This was wrong, because there is no binary compatibility guarantee that says
that the `stage0` DB's `package.cache` (which is written by the
stage0 == system-provided ghc-pkg) can be deserialised by the `ghc-pkg`
from the source code tree.
As a result, when trying to add fields to `InstalledPackageInfo` that get
serialised into / deserialised from the `package.cache`, errors like
_build/stage0/lib/package.conf.d/package.cache: GHC.PackageDb.readPackageDb: inappropriate type (Not a valid Unicode code point!)
would appear. This was because the `stage0/bin/ghc would try to
deserialise the newly added fields from
`_build/stage0/lib/package.conf.d/package.cache`, but they were not in there
because the system `ghc-pkg` doesn't know about them and thus didn't write them
there.
It would try to do that because any GHC by default tries to read the global
package db in `../lib/package.conf.d/package.cache`.
For `stage0/bin/ghc` that *can never work* as explained above, so we
must disable this default via `-no-global-package-db` and give it the
correct package DB explicitly.
This is the same problem as #16534, and the same fix as in MR !780
(but in another context; that one was for developers trying out the
`stage0/bin/ghc` == `_build/ghc-stage1` interactively, while this fix
is for a `cabal configure` invocation).
I also noticed that the fix for #16534 forgot to pass `-no-global-package-db`,
and have fixed that in this commit as well.
It only worked until now because nobody tried to add a new ghc-pkg `.conf`
field since the introduction of Hadrian.
|
| | |
|
| |
|
|
|
|
|
| |
Previously it was in ghc-boot so that ghc-pkg could use it. However it
wasn't necessary because ghc-pkg only uses a subset of it: reading
target arch and OS from the settings file. This is now done via
GHC.Platform.ArchOS (was called PlatformMini before).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Represent backends with a `Backend` datatype in GHC.Driver.Backend
* Don't detect the default backend to use for the target platform at
compile time in Hadrian/make but at runtime. It makes "Settings"
simpler and it is a step toward making GHC multi-target.
* The latter change also fixes hadrian which has not been updated to
take into account that the NCG now supports AIX and PPC64 (cf
df26b95559fd467abc0a3a4151127c95cb5011b9 and
d3c1dda60d0ec07fc7f593bfd83ec9457dfa7984)
* Also we don't treat iOS specifically anymore (cf
cb4878ffd18a3c70f98bdbb413cd3c4d1f054e1f)
|
| |
|
|
|
| |
This flag has been removed in 066b369de2c6f7da03c88206288dca29ab061b31
in 2011.
|
| |
|
|
| |
This is only for their respective codebases.
|
| | |
|
| |
|
|
|
|
|
|
| |
Follow-up of https://gitlab.haskell.org/ghc/ghc/-/issues/18403
This MR adds `fullCompilerVersion`, a function that shares the same
backend as the `--numeric-version` GHC flag, exposing a full,
three-digit version datatype.
|
| | |
|
| |
|
|
| |
Fixes #18361
|
| | |
|
| | |
|
| |
|
|
| |
Noticed by @Ericson2314
|
| | |
|
| | |
|
| | |
|
| | |
|
