Skip to content

Conversation

@hasufell
Copy link
Member

@hasufell hasufell commented Nov 12, 2025

DO NOT MERGE

This PR is just to show the diff.


stage2 fails with https://gist.github.com/hasufell/5a7b4331cea6af86e7a3588a5cce539c

@hasufell hasufell marked this pull request as draft November 12, 2025 08:43
@hasufell
Copy link
Member Author

@angerman
Copy link

This is probably related to https://gitlab.haskell.org/ghc/ghc/-/commit/99f980acad123f08136a9a517b4de8a01481faa3

The current issue is:

diff --git a/rts/rts.cabal b/rts/rts.cabal
index a725bb5606..84da747164 100644
--- a/rts/rts.cabal
+++ b/rts/rts.cabal
@@ -375,6 +375,7 @@ common rts-c-sources-base
                adjustor/AdjustorPool.c
                ExecPage.c
                Arena.c
+               BuiltinClosures.c
                Capability.c
                CheckUnload.c
                CheckVectorSupport.c

However, there are more subsequent issues. I think we should maybe explore a route that does not reverse the patchset, but accepts it, and then double down on cutting down stage1 requirements (e.g. do we actually need this Stack stuff in stage1 or can we just conditionally disable it)?

angerman and others added 23 commits November 20, 2025 12:10
This change reverts part of !14544, which forces the bootstrap
compiler to have ghc-internal.  As such it breaks booting with
ghc 9.8.4. A better solution would be to make this conditional
on the ghc version in the cabal file!
…ernal

If the boot compiler doesn't have ghc-internal use "<unavailble>" as the
`cGhcInternalUnitId`.  This allows booting with older compilers. The
subsequent stage2 compilers will have the proper ghc-internal id from
their stage1 compiler, that boots them.
mermaid is a common diagram format that can be inlined in markdown
files, and e.g. github will even render it.  This change adds
support for mermaid diagram output to ghc-pkg.
This adds support to ghc-pkg to infer a package-db from a target name.
Make the first simple optimization pass after desugaring a real CoreToDo
pass. This allows CorePlugins to decide whether they want to be executed
before or after this pass.
It's more user-friendly to directly print the right thing instead of
requiring the user to retry with the additional `-dppr-debug` flag.
The referenced issue 20706 also doesn't list T13786 as a broken test.
By mistake we tried to use deriveConstant without passing
`--gcc-flag -fcommon` (which Hadrian does) and it failed.

This patch adds deriveConstant support for constants stored in the .bss
section so that deriveConstant works without passing `-fcommon` to the C
compiler.
This commit restructures the Runtime System (RTS) components for better
modularity and reusability across different build configurations. The
changes enable cleaner separation of concerns and improved support for
cross-compilation scenarios.

Key changes:
- Extract RTS headers into standalone rts-headers package
  * Moved include/rts/Bytecodes.h to rts-headers
  * Moved include/rts/storage/ClosureTypes.h to rts-headers
  * Moved include/rts/storage/FunTypes.h to rts-headers
  * Moved include/stg/MachRegs/* to rts-headers
- Create rts-fs package for filesystem utilities
  * Extracted filesystem code from utils/fs
  * Provides reusable filesystem operations for RTS
- Rename utils/iserv to utils/ghc-iserv for consistency
  * Better naming alignment with other GHC utilities
  * Updated all references throughout the codebase
- Update RTS configuration and build files
  * Modified rts/configure.ac for new structure
  * Updated rts.cabal with new dependencies
  * Adjusted .gitignore for new artifacts

Rationale:
The modularization allows different stages of the compiler build to
share common RTS components without circular dependencies. This is
particularly important for:
- Cross-compilation where host and target RTS differ
- JavaScript backend which needs selective RTS components
- Stage1/Stage2 builds that require different RTS configurations

Contributors:
- Moritz Angermann: RTS modularization architecture and implementation
- Sylvain Henry: JavaScript backend RTS adjustments
- Andrea Bedini: Build system integration

This refactoring maintains full backward compatibility while providing
a cleaner foundation for multi-target support.
hasufell and others added 23 commits November 20, 2025 12:10
Fixes #26434

In detail, this does a number of things:
* Makes GHC aware of 'extra-libraries-static' (this changes the package
  database format).
* Adds a switch '-static-external' that will honour 'extra-libraries-static'
  to link external system dependencies statically.
* Adds a new field to settings/targets: "ld supports verbatim namespace".
  This field is used by '-static-external' to conditionally use '-l:foo.a'
  syntax during linking, which is more robust than trying to find the
  absolute path to an archive on our own.
* Adds a switch '-fully-static' that is meant as a high-level interface
  for e.g. cabal. This also honours 'extra-libraries-static'.

This also attempts to clean up the confusion around library search directories.
At the moment, we have 3 types of directories in the package database
format:
* library-dirs
* library-dirs-static
* dynamic-library-dirs

However, we only have two types of linking: dynamic or static. Given the
existing logic in 'mungeDynLibFields', this patch assumes that
'library-dirs' is really just nothing but a fallback and always
prefers the more specific variants if they exist and are non-empty.

Conceptually, we should be ok with even just one search dirs variant.
Haskell libraries are named differently depending on whether they're
static or dynamic, so GHC can conveniently pick the right one depending
on the linking needs. That means we don't really need to play tricks
with search paths to convince the compiler to do linking as we want it.
For system C libraries, the convention has been anyway to place static and
dynamic libs next to each other, so we need to deal with that issue
anyway and it is outside of our control. But this is out of the scope
of this patch.

This patch is backwards compatible with cabal. Cabal should however
be patched to use the new '-fully-static' switch.
"Executable" seems more appropriate.
Since we now ignore loading ANY rts dependency.
@angerman angerman force-pushed the stable-ghc-9.14.2025.11.12 branch from a3f5e08 to 56bd0c5 Compare November 20, 2025 09:51
@angerman angerman force-pushed the stable-ghc-9.14.2025.11.12 branch from 56bd0c5 to 0db5e12 Compare November 20, 2025 09:56
@angerman angerman force-pushed the stable-ghc-9.14.2025.11.12 branch from fda77d9 to 210bee8 Compare November 21, 2025 06:09
@angerman angerman force-pushed the stable-ghc-9.14.2025.11.12 branch from 210bee8 to 257a3dc Compare November 21, 2025 06:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants