`rts-headers` package complications when build `compiler` with a compiler that has `rts-headers`.

[angerman]

This basically means, the compiler (when built) is linked against a newer set of headers, than what the boot compiler provides. Am I missing something more here?

Thus if we make the boot compiler build rts-headers (the new ones from source), and use those when building the compiler. It would see the new headers?

Case 1: boot compiler without rts-headers

1. we build rts-headers
2. we build compiler against these rts-headers (yet link the binary against the old rts, as the compiler, and it's rts are symbiotic)

Case 1: boot compiler with rts-headers package.

1. we build the rts-headers package (and augment/shadow/replace the one the boot compiler has)
2. we build the compiler against these (new) rts-headers (yet link the binary against the old (boot compiler) rts).

My understanding is: we always want the compiler to see the latest headers when building the compiler package.

The complication @hsyl20 correctly outlined about is that

+ compiler
   + rts
      + rts-headers

As such, we can't just trivially repalce the rts-headers here.

We could make the compiler during bootstrap not depend on the rts, and rely on ghc always injecting the rts package anyway when linking?

This is a bit similar to the ghc-boot-th[-next] issue.

[angerman]

See also these comments:

• Stable ghc 9.14 #42 (comment)
• Stable ghc 9.14 #42 (comment)

The cabal.project.stage1 has the following comment:

-- NOTE: we need rts-headers, because the _newly_ built compiler depends
  --       on these potentially _new_ headers, we must not rely on those from
  --       the rts as shipped with the bootstrap compiler. For the stage2
  --       compiler we have the `rts` available, which would have the correct
  --       headers around, now it has them through the rts -> rts-headers
  --       dependency.
  rts-headers
  rts-fs

[hsyl20]

Related to #12