- May 05, 2024
-
-
The `ghc-toolchain` overhaul will eventually replace all this stuff with something much more cleaned up, but I think it is still worth making this sort of cleanup in the meantime so other untanglings and dead code cleaning can procede. I was able to delete a fair amount of dead code doing this too. `LLVMTarget_CPP` is renamed to / merged with `LLVMTarget` because it wasn't actually turned into a valid CPP identifier. (Original to 1345c7cc, actually.) Progress on #23966 Co-Authored-By:
Sylvain Henry <hsyl20@gmail.com>
-
- Mar 19, 2024
-
-
Previously there were two instances in this script which lacked proper quoting. This resulted in `relpath` invocations in the binary distribution Makefile producing incorrect results on Windows, leading to confusing failures from `sed` and the production of empty package registrations. Fixes #24538.
-
- Feb 21, 2024
-
-
We must generate the hsc2hs wrapper at bindist installation time since it must contain `--lflag` and `--cflag` arguments which depend upon the installation path. The solution here is to substitute these variables in the configure script (see mk/hsc2hs.in). This is then copied over a dummy wrapper in the install rules. Fixes #24050.
-
- Sep 21, 2023
-
-
- Jul 24, 2023
-
-
This commit integrates ghc-toolchain, the brand new way of configuring toolchains for GHC, with the Hadrian build system, with configure, and extends and improves the first iteration of ghc-toolchain. The general overview is * We introduce a program invoked `ghc-toolchain --triple=...` which, when run, produces a file with a `Target`. A `GHC.Toolchain.Target.Target` describes the properties of a target and the toolchain (executables and configured flags) to produce code for that target * Hadrian was modified to read Target files, and will both * Invoke the toolchain configured in the Target file as needed * Produce a `settings` file for GHC based on the Target file for that stage * `./configure` will invoke ghc-toolchain to generate target files, but it will also generate target files based on the flags configure itself configured (through `.in` files that are substituted) * By default, the Targets generated by configure are still (for now) the ones used by Hadrian * But we additionally validate the Target files generated by ghc-toolchain against the ones generated by configure, to get a head start on catching configuration bugs before we transition completely. * When we make that transition, we will want to drop a lot of the toolchain configuration logic from configure, but keep it otherwise. * For each compiler stage we should have 1 target file (up to a stage compiler we can't run in our machine) * We just have a HOST target file, which we use as the target for stage0 * And a TARGET target file, which we use for stage1 (and later stages, if not cross compiling) * Note there is no BUILD target file, because we only support cross compilation where BUILD=HOST * (for more details on cross-compilation see discussion on !9263) See also * Note [How we configure the bundled windows toolchain] * Note [ghc-toolchain consistency checking] * Note [ghc-toolchain overview] Ticket: #19877 MR: !9263
-
- Jul 05, 2023
-
-
Solaris 11 was released over a decade ago and, moreover, I doubt we have any Solaris users
-
- Feb 03, 2023
-
-
Updates to LLVM 14, hopefully fixing #21964.
-
- Aug 26, 2022
-
-
-
This is only used by nofib's dead `dist` target
-
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
-
- Aug 18, 2022
-
-
Since 2011 the object-joining implementation has had a hack to pass `--build-id=none` to `ld` when supported, seemingly to work around a linker bug. This hack is now unnecessary and may break downstream users who expect objects to have valid build-ids. Remove it. Closes #22060.
-
- Aug 09, 2022
-
-
It turns out that `cp -P` on Darwin does not always copy a symlink as a symlink. In order to get these semantics one must pass `-RP`. It's not entirely clear whether this is valid under POSIX, but it is nevertheless what Apple does.
-
- May 17, 2022
-
-
Here we introduce a new "virtual" package into the initial package database, `system-cxx-std-lib`. This gives users a convenient, platform agnostic way to link against C++ libraries, addressing #20010. Fixes #20010.
-
Here we introduce proper support for compilation of C++ objects. This includes: * logic in `configure` to detect the C++ toolchain and propagating this information into the `settings` file * logic in the driver to use the C++ toolchain when compiling C++ sources
-
- Apr 27, 2022
-
-
Here we deprecate the eventlogging RTS ways and instead enable eventlog support in the remaining ways. This simplifies packaging and reduces GHC compilation times (as we can eliminate two whole compilations of the RTS) while simplifying the end-user story. The trade-off is a small increase in binary sizes in the case that the user does not want eventlogging support, but we think that this is a fine trade-off. This also revealed a latent RTS bug: some files which included `Cmm.h` also assumed that it defined various macros which were in fact defined by `Config.h`, which `Cmm.h` did not include. Fixing this in turn revealed that `StgMiscClosures.cmm` failed to import various spinlock statistics counters, as evidenced by the failed unregisterised build. Closes #18948.
-
- Apr 25, 2022
-
-
Drop libtool logic from gen-dll, allowing us to drop the remaining logic from the `configure` script. Strangely, this appears to reliably reduce compiler allocations of T16875 on Windows. Closes #18826. Metric Decrease: T16875
-
- Apr 22, 2022
-
-
As of #18487 we no longer support 32-bit Windows. Fixes #21372.
-
- Apr 06, 2022
-
-
Ben Gamari authored
* Bump win32-tarballs to 0.7 * Move Windows toolchain autoconf logic into separate file * Use clang and LLVM utilities as described in #21019 * Disable object merging as lld doesn't support -r * Drop --oformat=pe-bigobj-x86-64 arguments from ld flags as LLD detects that the output is large on its own. * Drop gcc wrapper since Clang finds its root fine on its own.
-
Since there may be .o files which are in fact archives.
-
- Feb 08, 2022
-
-
- Feb 01, 2022
-
-
- Jan 29, 2022
-
-
Ben Gamari authored
-
-
- Jan 12, 2022
-
-
- Dec 02, 2021
-
-
As noted in #19963, `realpath` is not specified by POSIX and therefore cannot be assumed to be available. Here we provide a POSIX shell implementation of `realpath`, due to Julian Ospald and others. Closes #19963.
-
- Nov 27, 2021
-
-
John Ericson authored
Get rid of `USE_INPLACE_MINGW_TOOLCHAIN` and use a settings file entry instead. The CPP setting was originally introduced in f065b6b0.
-
- Nov 15, 2021
-
-
These dirs should not be included in all stages. Instead make the per-stage `BUILD_*_INCLUDE_DIR` "plural" to insert `rts/include` in the right place.
-
- Nov 13, 2021
-
-
Before we were violating the convention of every other package. This fixes that. It matches the changes made in d5de970d to the location of the files in the repo.
-
- Oct 31, 2021
-
-
These are best thought of as being part of the RTS. - After !6791, `ghcautoconf.h` won't be used by the compiler inappropriately. - `ghcversion.h` is only used once outside the RTS, which is `compiler/cbits/genSym.c`. Except we *do* mean the RTS GHC is built against there, so it's better if we always get get the installed version. - `ghcplatform.h` alone is used extensively outside the RTS, but since we no longer have a target platform it is perfectly safe/correct to get the info from the previous RTS. All 3 are exported from the RTS currently and in the bootstrap window. This commit just swaps directories around, such that the new headers may continue to be used in stage 0 despite the reasoning above, but the idea is that we can subsequently make more interesting changes doubling down on the reasoning above. In particular, in !6803 we'll start "morally" moving `ghcautonconf.h` over, introducing an RTS configure script and temporary header of its `AC_DEFINE`s until the top-level configure script doesn't define any more. Progress towards #17191
-
- Oct 25, 2021
-
-
I think this hasn't been a thing since 86054b4a, almost 10 years ago!
-
- Sep 22, 2021
-
-
The compiler should be independent of the target.
-
- Aug 09, 2021
-
-
In order to make the packages in this repo "reinstallable", we need to associate source code with a specific packages. Having a top level `/includes` dir that mixes concerns (which packages' includes?) gets in the way of this. To start, I have moved everything to `rts/`, which is mostly correct. There are a few things however that really don't belong in the rts (like the generated constants haskell type, `CodeGen.Platform.h`). Those needed to be manually adjusted. Things of note: - No symlinking for sake of windows, so we hard-link at configure time. - `CodeGen.Platform.h` no longer as `.hs` extension (in addition to being moved to `compiler/`) so as not to confuse anyone, since it is next to Haskell files. - Blanket `-Iincludes` is gone in both build systems, include paths now more strictly respect per-package dependencies. - `deriveConstants` has been taught to not require a `--target-os` flag when generating the platform-agnostic Haskell type. Make takes advantage of this, but Hadrian has yet to.
-
- Jul 27, 2021
-
-
- Jun 05, 2021
-
-
In which we add a new code generator to the Glasgow Haskell Compiler. This codegen supports ELF and Mach-O targets, thus covering Linux, macOS, and BSDs in principle. It was tested only on macOS and Linux. The NCG follows a similar structure as the other native code generators we already have, and should therfore be realtively easy to follow. It supports most of the features required for a proper native code generator, but does not claim to be perfect or fully optimised. There are still opportunities for optimisations. Metric Decrease: ManyAlternatives ManyConstructors MultiLayerModules PmSeriesG PmSeriesS PmSeriesT PmSeriesV T10421 T10421a T10858 T11195 T11276 T11303b T11374 T11822 T12227 T12545 T12707 T13035 T13253 T13253-spj T13379 T13701 T13719 T14683 T14697 T15164 T15630 T16577 T17096 T17516 T17836 T17836b T17977 T17977b T18140 T18282 T18304 T18478 T18698a T18698b T18923 T1969 T3064 T5030 T5321FD T5321Fun T5631 T5642 T5837 T783 T9198 T9233 T9630 T9872d T9961 WWRec Metric Increase: T4801
-
- May 25, 2021
-
-
This is so awful, but at least it might get the job done.
-
- Apr 07, 2021
-
-
Dynamic-by-default was a mechanism to automatically select the -dynamic way for some targets. It was implemented in a convoluted way: it was defined as a flavour option, hence it couldn't be passed as a global settings (which are produced by `configure` before considering flavours), so a build system rule was used to pass -DDYNAMIC_BY_DEFAULT to the C compiler so that deriveConstants could infer it. * Make build system has it disabled for 8 years (951e28c0) * It has never been implemented in Hadrian * Last time someone tried to enable it 1 year ago it didn't work (!2436) * Having this as a global constant impedes making GHC multi-target (see !5427) This commit fully removes support for dynamic-by-default. If someone wants to reimplement something like this, it would probably need to move the logic in the compiler. (Doing this would probably need some refactoring of the way the compiler handles DynFlags: DynFlags are used to store and to pass enabled ways to many parts of the compiler. It can be set by command-line flags, GHC API, global settings. In multi-target GHC, we will use DynFlags to load the target platform and its constants: but at this point with the current DynFlags implementation we can't easily update the existing DynFlags with target-specific options such as dynamic-by-default without overriding ways previously set by the user.)
-
- Mar 05, 2021
-
-
This enables a registerised build for the riscv64 architecture.
-
- Oct 09, 2020
-
-
This should fix #18774.
-
- Sep 11, 2020
-
-
- Sep 08, 2020
-
-
In b592bd98 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)
-
