Skip to content

On hold: Deprecate -dynamic-too: remove duplicate object file generation - #122

Open
angerman wants to merge 100 commits into
stable-ghc-9.14from
feature/remove-dyn-too
Open

angerman wants to merge 100 commits into
stable-ghc-9.14from
feature/remove-dyn-too

Conversation

@angerman

@angerman angerman commented Dec 3, 2025

Copy link
Copy Markdown

Summary

This PR deprecates the -dynamic-too flag and removes the infrastructure that generated separate .dyn_o and .dyn_hi files alongside regular .o and .hi files.

  • The -dynamic-too flag now emits a deprecation warning and is a no-op
  • GHC no longer produces .dyn_o or .dyn_hi files
  • Only standard .o and .hi files are generated
  • ModLocation API preserved for compatibility (dyn paths return same as non-dyn paths)

Changes

File Changes
GHC/Driver/Session.hs Flag now deprecated with warning
GHC/Driver/Downsweep.hs Removed dynamic_too_enable auto-enablement
GHC/Driver/Pipeline.hs Removed backend double-run
GHC/Driver/DynFlags.hs Removed DynamicTooState, dynamicNow, setDynamicNow
GHC/Driver/Main.hs Simplified interface writing (single .hi)
GHC/Driver/Pipeline/Execute.hs Removed dynamicNow path checks
GHC/Iface/Load.hs Removed load_dynamic_too* functions
GHC/Iface/Recomp.hs Removed check_dyn_hi logic
GHC/Tc/Utils/Monad.hs Removed withoutDynamicNow
GHC/Unit/Finder.hs mkDynObjPath = mkObjPath, mkDynHiPath = mkHiPath
GHC/Linker/Loader.hs dyn_obj_file = obj_file
GHC/Linker/Deps.hs Updated comments

Breaking Changes

  • Build systems that rely on .dyn_o files will need to be updated to use regular .o files
  • The -dynamic-too flag no longer has any effect (deprecation warning emitted)

Test plan

  • Verify deprecation warning is emitted when using -dynamic-too
  • Verify only .o and .hi files are produced (no .dyn_o or .dyn_hi)
  • Run testsuite to check for regressions
  • Test TemplateHaskell compilation still works without auto-enablement

@hasufell

Copy link
Copy Markdown
Member

I had to add this patch:

--- a/compiler/GHC/Driver/DynFlags.hs
+++ b/compiler/GHC/Driver/DynFlags.hs
@@ -997,6 +997,7 @@ dopt_unset dfs f = dfs{ dumpFlags = EnumSet.delete f (dumpFlags dfs) }

 -- | Test whether a 'GeneralFlag' is set
 gopt :: GeneralFlag -> DynFlags -> Bool
+gopt Opt_ExternalDynamicRefs _ = True
 gopt f dflags = f `EnumSet.member` generalFlags dflags

 -- | Set a 'GeneralFlag'

otherwise I'd run into errors such as:

/usr/lib64/gcc/x86_64-suse-linux/15/../../../../x86_64-suse-linux/bin/ld: /home/hasufell/git/ghc/_build/stage2/build/host/x86_64-linux/ghc-9.14/ghc-internal-9.1400.0/build/GHC/Internal/Event/TimerManager.o: warning: relocation against `stg_INTLIKE_closure' in read-only section `.text'
/usr/lib64/gcc/x86_64-suse-linux/15/../../../../x86_64-suse-linux/bin/ld: /home/hasufell/git/ghc/_build/stage2/build/host/x86_64-linux/ghc-9.14/ghc-internal-9.1400.0/build/GHC/Internal/AllocationLimitHandler.o: relocation R_X86_64_PC32 against undefined symbol `stg_bh_upd_frame_info' can not be used when making a shared object; recompile with -fPIC
/usr/lib64/gcc/x86_64-suse-linux/15/../../../../x86_64-suse-linux/bin/ld: final link failed: bad value

But that would open issues with cabal not knowing which interface/object files to pick and invoking GHC incorrectly. After fixing that... I realized it now invokes the boot compiler (non-stable-haskell) wrongly xD

At that point, I wasn't sure if I want to continue this route.

@angerman
angerman force-pushed the feature/remove-dyn-too branch 3 times, most recently from 6a4d55f to 2f7b22e Compare February 14, 2026 04:12
@angerman

Copy link
Copy Markdown
Author

A for now lighter version of this is in #147.

@angerman angerman changed the title Deprecate -dynamic-too: remove duplicate object file generation On hold: Deprecate -dynamic-too: remove duplicate object file generation Feb 19, 2026
angerman and others added 19 commits March 5, 2026 12:35
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.
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.
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.
Add a new optional unitDataDir field to GhcPkg.InstalledPackageInfo
and populate it in ghc-pkg's convertPackageInfoToCacheFormat.

This is needed by the WASM linker to locate per-package data files
(specifically WasmGlobalRegs.S) via GHC.Unit.Database.unitDataDir
at link time, without requiring a file-system search.
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.
Apple's LLVM toolchain uses `arm64` as the canonical architecture name
for AArch64 on Apple platforms, while GNU config.sub normalises to
`aarch64`. This mismatch causes `--target=aarch64-apple-darwin` to be
passed to clang, which conflicts with toolchain wrappers (e.g. nix
cc-wrapper) that expect `arm64-apple-darwin`.

The result is thousands of test failures on aarch64-darwin because the
cc-wrapper warning pollutes compiler output and the target flag
interaction breaks compilation.

Fix by adding normaliseLlvmTarget that rewrites `aarch64-apple-*` to
`arm64-apple-*` for the LLVM target triple, matching Apple conventions
and the existing llvm-targets file which already uses arm64-apple-darwin.
Add AC_ARG_WITH([compiler]) to allow specifying the Haskell compiler
via the --with-compiler flag, consistent with standard autoconf practices
for tool configuration.

This provides an alternative to setting the GHC environment variable,
making the build system more flexible and consistent with other
configure scripts that accept --with-* options for tools.
Add entries to prevent AI agent config files from being accidentally
committed. These files contain project-specific instructions for various
AI coding assistants and should remain local.

Covers: Claude Code, GitHub Copilot, Cursor, Gemini CLI/Jules,
OpenAI Codex, and JetBrains Junie.

See: https://agents.md/ for the AGENTS.md standard
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.
hasufell and others added 18 commits March 5, 2026 12:44
This commit adds build system support for creating dynamic GHC builds,
including Makefile targets, bindist generation, and utility configurations.

Key changes:

1. Makefile enhancements
   - Add DYNAMIC=1 build variable support
   - Create dylib symlinks for macOS dynamic builds
   - Use concrete file target for testsuite-timeout
   - Include ghc-iserv-dyn in tarballs for all targets
   - Proper bindist generation for dynamic builds

2. Utility cabal files (hp2ps.cabal, unlit.cabal)
   - Configure for dynamic linking support
   - Ensure utilities work with dynamic GHC

3. ghc-iserv infrastructure (iservmain.c)
   - Updates for dynamic interpreter server
   - Proper initialization for dynamic linking context

4. Test expectations for Stable Haskell
   - Update bug report URL in test expectations

Usage:
  make DYNAMIC=1 _build/bindist  # Build dynamic GHC bindist
This commit adds infrastructure for RTS sublibrary loading in dynamic builds,
enabling the split RTS architecture to work with shared library linking.

Key changes:

1. RTS sublibrary infrastructure (rts/rts.cabal)
   - Define separate sublibraries for RTS components
   - Add proper library dependencies and visibility
   - Configure shared library generation for RTS parts

2. Configure support for dynamic builds (rts/configure.ac)
   - Detect platform-specific dynamic linking requirements
   - Set appropriate linker flags for each sublibrary
   - Handle symbol visibility for exported functions

3. API updates for sublibrary boundaries (rts/include/RtsAPI.h)
   - Adjust exported symbol declarations
   - Ensure proper visibility across sublibrary boundaries

4. AutoApply support for interpreter (rts/AutoApply*.cmm)
   - Add AutoApply.cmm and vector variants (V16, V32, V64)
   - Required for dynamic bytecode interpreter operation

5. Cabal project configuration
   - cabal.project.stage1: Add no-ghc-internal flag for stage1 builds
   - cabal.project.stage2: Configure full RTS with all sublibraries

6. Thread infrastructure (rts/Threads.h)
   - Updates for sublibrary thread handling
This commit updates the testsuite to handle the split RTS architecture
and dynamic GHC build configuration.

Key changes:

1. testlib.py improvements
   - More robust test driver for dynamic builds
   - Better handling of shared library paths
   - Improved error detection and reporting

2. Test infrastructure (boilerplate.mk)
   - Configure tests for dynamic linking environment
   - Set proper library paths for test execution

3. Test adjustments for RTS split
   - T18072debug: Update grep to match cabal-based RTS naming
   - T23142.hs: Revert module name to fix -Di debug output test
   - keep-cafs-fail.stdout: Update expected output

4. Dynamic linking test updates
   - ghci/linking/dyn/all.T: Adjust for dynamic GHC
   - T2228: Restore expect_broken(7298) for dynamic builds
   - T11531.stderr: Update expected error messages

5. Platform-specific adjustments
   - T10458: Skip on musl with dynamic GHC
   - T11223 tests: Update stderr expectations for Windows

6. Test configuration
   - .gitignore: Add patterns for dynamic test artifacts
   - dynlibs/Makefile: Update for dynamic build testing
   - perf/size/all.T: Adjust size expectations
Add "Stable Haskell Edition" branding to user-visible output while
maintaining drop-in compatibility with upstream GHC:

- ghc --version: Append "(Stable Haskell Edition)" suffix
- ghc -v2 banner: Add edition to verbose compiler banner
- GHCi welcome: Add edition and update URL to GitHub repo
- ghc --info: Add new "Edition" field (keeps "Project name" unchanged)
- Bug reports: Redirect all URLs to github.com/stable-haskell/ghc/issues

All internal identifiers (cProjectVersion, unit IDs, etc.) remain
unchanged to preserve ABI and tool compatibility.
The branding commit changed the bug report URL from
haskell.org/ghc/reportabug to github.com/stable-haskell/ghc/issues.
Update test expectation files to match the new URL output.

Fixes CI failures in T11223_link_order_a_b_2_fail and
T11223_simple_duplicate_lib tests across all platforms.
This commit extends the CI/CD pipeline to build and test dynamic GHC
configurations alongside the existing static builds.

Key changes:

1. ci.yml - Main CI workflow
   - Add DYNAMIC=1 to build matrix
   - Configure dynamic build jobs for Linux and macOS
   - Run ghci-ext tests on dynamic builds (require interpreter)
   - Parallel execution of static and dynamic builds

2. reusable-release.yml - Release workflow
   - Add dynamic GHC builds to release artifacts
   - Generate separate bindists for dynamic configuration
   - Include ghc-iserv-dyn in release tarballs
   - Re-enable release workflow on pull requests for testing

The dynamic build matrix allows testing of:
- Template Haskell with dynamic code loading
- GHCi interactive features
- Dynamic library loading and linking
- Interpreter-based test suites (ghci-ext)

Build configurations:
- Static (default): DYNAMIC=0 or unset
- Dynamic: DYNAMIC=1
Add GitHub Actions release workflow with reusable build/test jobs,
artifact upload/download, and proper _build/dist output paths.
Add QUIET mode for reduced output, per-phase timing instrumentation,
metrics collection scripts, and matplotlib-based build phase plots.
Includes macOS fixes and review feedback.
Since we now ignore loading ANY rts dependency.
- Add AR/RANLIB variables for wasm32-wasi-ar and wasm32-wasi-ranlib
  (explicit tool paths for cross-compilation)
- Add --disable-libffi-adjustors to GHC_TOOLCHAIN_ARGS (wasm32 has
  no native adjustors, so ghc-toolchain defaults to libffi, but
  WASI cannot support ffi_closure_alloc which requires W^X memory;
  note: +use-system-libffi for general FFI is separate and correct)
- Add -fno-exceptions to CXX_OPTS (wasi-sdk libc++ has no exception
  support)
* hsc2hs: batch cross-compilation for massive speedup

Replace hackage hsc2hs-0.68.10 with stable-haskell/hsc2hs fork that
includes batch cross-compilation support. This reduces C compiler
invocations from hundreds/thousands per .hsc file to just 1-2 total
by batching all constant-like directives (#const, #size, #alignment,
step with graceful fallback to per-directive compilation.

Key changes in the fork (bf966e8):
- Batch collection of all batchable directives with conditional stack tracking
- Single C file generation with all constants as global variables
- Assembly parsing via ATTParser to extract all values at once
- Graceful try/catch around ATT.parse for compilers producing non-AT&T
  assembly (e.g. emcc for WebAssembly), falling through to per-directive path
- --no-batch flag for debugging/fallback

Performance impact per .hsc file:
- Before (non-via-asm): ~28 compilations per directive (e.g. 4089 for Flags.hsc)
- Before (via-asm): 1 compilation per directive (e.g. 147 for Flags.hsc)
- After (batch): 2 compilations total per file (validity check + batch)

Fork: https://github.com/stable-haskell/hsc2hs/tree/feat/batch-cross-compilation

* fix: update hsc2hs fork with Windows CodeView debug section fix

Update hsc2hs fork reference to include fix for ATT parser crash on
Windows where Clang emits CodeView .debug$S sections even with -g0.
The parser now filters out debug sections and handles unrecognized
instruction patterns gracefully.
.nix-wasm-bin/         — symlink directory created by flake.nix pointing
                         into the Nix store for wasi-sdk tools; local only
.nixos-remote-build.conf — per-machine config for the remote Linux build
                           helper script; not part of the source tree
angerman added 8 commits March 6, 2026 10:12
This commit deprecates the -dynamic-too flag and removes the infrastructure
that generated separate .dyn_o and .dyn_hi files alongside regular .o and .hi
files.

Key changes:
- Flag -dynamic-too now emits a deprecation warning and is a no-op
- Remove auto-enablement of -dynamic-too for TemplateHaskell
- Remove pipeline double-run that generated both static and dynamic objects
- Remove DynamicTooState type and dynamicNow field from DynFlags
- Remove dynamicTooState and setDynamicNow functions
- Unify dyn/non-dyn file paths (mkDynObjPath = mkObjPath, etc.)
- Remove dynamic interface loading and checking
- Update linker to use .o files for dynamic loading

The ModLocation fields (ml_dyn_obj_file, ml_dyn_hi_file) are kept for API
compatibility but now return the same paths as their non-dyn counterparts.

Build systems that rely on .dyn_o files will need to be updated to use
regular .o files instead.
Since -dynamic-too is now a deprecated no-op, reporting YES caused Cabal
to use single-pass mode expecting both .o and .dyn_o output. Only .o was
produced, breaking shared library linking in DYNAMIC=1 builds.

Reporting NO makes Cabal fall back to two-pass compilation (vanilla +
dynamic), which correctly produces both .o and .dyn_o files. The double
compilation is slightly wasteful since both passes yield identical
dynamic-capable objects, but it is correct and unblocks all DYNAMIC=1 CI
jobs.
Since -dynamic-too is deprecated and all .o files are now
dynamic-capable, WayDyn no longer implies a separate object file
suffix (.dyn_o). The checkNonStdWay function previously returned
Just "dyn_o" when the host GHC was dynamic but the target ways
didn't include WayDyn, causing the linker to look for non-existent
.dyn_o files when loading TH/plugin/GHCi code.

Fix by comparing ways modulo WayDyn: since .o files are always
dynamic-capable, only non-dynamic ways (like WayProf) affect the
object file suffix. This resolves ~45 TH/plugin test failures.
Since -dynamic-too is deprecated and a no-op (all .o files are now
dynamic-capable), skip all tests that specifically exercise -dynamic-too
functionality:

- dynamicToo001, dynamicToo001boot, dynamicToo001MakeA/B, dynamicToo002,
  dynamicToo003, dynamicToo004, dynamicToo005, dynamicToo006,
  dynamicTooMake, dynamicTooRecomp, dynamicTooOnlyInterface
- T20348A-E (test -dynamic-too output file options)
- T25837 (tests dynamic interface mismatch detection)
- recomp-boot-dyn-too (tests -dynamic-too with boot files)
- implicit-dyn-too (tests missing .dyn_o recompilation)

Updated tests:
- T20348: removed .dyn_o/.dyn_hi checks from Makefile and stdout
- T20436: updated expected stderr to new deprecation warning
- T23944: removed -dynamic-too from compilation flags
- T12983: replaced -dynamic-too with -dynamic in build.sh
- recompPluginPackage: replaced -dynamic-too with -dynamic in q.cabal
…bjects

Since all .o files are now dynamic-capable and -dynamic-too is a no-op,
compilation progress messages no longer show .dyn_o output files. Update
golden files and test configurations accordingly:

- Remove .dyn_o from progress messages in golden files (T20696, fat015,
  SI07, T22840, multipleHomeUnits_single5)
- Replace -dynamic-too with -dynamic in test configs (T22840, T19264,
  T21035, T14931)
- Update T21035 Makefile to use .o files directly for shared lib creation
- Update T20696 wasm32-specific stderr to match new output
With dynamic-too deprecated and all .hi/.o files unified, the Finder's
package_hisuf computation must ignore WayDyn when computing the build
tag. Previously, when WayDyn was in finder_ways, the tag would be "dyn"
causing lookups for ".dyn_hi" files in package directories - but
packages now install unified ".hi" files only.

This is the same pattern as the checkNonStdWay fix in Linker/Deps.hs
(commit 8a64142): use removeWay WayDyn so only non-dynamic ways (e.g.
profiling) contribute to the suffix.

Fixes T14304 and T16219 (backpack signature interface lookup failures
under -dynamic builds).
T21035: Remove -dynamic from HsDep.hs compilation. With unified object
files, all .o files are dynamic-capable, so plain compilation produces
a .hi with empty profile tag compatible with non-dynamic consumers.
The old -dynamic flag wrote profile tag "dyn" into the .hi, causing
a mismatch when M.hs compiled without -dynamic tried to read it.

T20436: Remove leading newline from golden stderr. The deprecation
warning is now emitted during flag parsing (via deprecate) rather than
after flag processing (via makeDynFlagsConsistent), so no leading
blank line is produced.

T22840: Update golden file to expect "interpreted" for T22840A. With
-dynamic-too gone, the --make pipeline propagates byte-code compilation
to T22840A (a dependency of TH-using modules) since -dynamic without
-dynamic-too triggers the byte-code+object-code path for dependencies.
With -dynamic-too deprecated and all .hi/.o files unified, WayDyn no
longer affects the ABI of interface or object files. The profile build
tag (used for interface file compatibility checks in Iface/Binary.hs)
must not include the "dyn" component, otherwise we get:

    mismatched interface file profile tag (wanted "dyn", got "")

This occurs when Cabal builds packages with --enable-shared (-dynamic)
using a stage2 compiler whose libraries were compiled without -dynamic.
The .hi files have tag "" but the reader expects "dyn".

By filtering WayDyn from the ways before computing waysBuildTag, both
the writing and reading sides produce consistent tags regardless of
whether -dynamic is passed. This follows the same pattern as the Finder
and Linker fixes (commits 59cc152, 8a64142).
@angerman
angerman force-pushed the feature/remove-dyn-too branch from 5664b63 to 94cf05a Compare March 6, 2026 01:12
@angerman
angerman force-pushed the stable-ghc-9.14 branch 2 times, most recently from 8bdf55f to 93c3dc1 Compare August 30, 2026 01:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants