Skip to content

GHC as a test case for complications with cross-compiling #21874

@shlevy

Description

@shlevy

Since #21268 (or something like it) will hopefully be merged soon, I want to outline the ways in which GHC, as an example, violates the strict staging that PR wants.

First, the GHC build includes support libraries for the target system. In principle, this could be kept with the desired staging with multiple outputs, and including the target libs in the next stage, but it will likely be complicated to do. This issue exists for gcc which has libstdc++, and llvm as it currently exists with compiler-rt etc. build at the same time as the compiler.

Second, and harder to disentangle without upstream support for separating, the GHC build includes binaries intended to run on the target platform (in particular, iserv, whose whole purpose is to be able to run target code during compile time). Putting these in separate outputs won't be enough: They will also depend on target libs as inputs (e.g. libiconv in the iserv case).

In principle, both of these could (and probably should) be separated out into different builds from the core compiler itself. But I write this up as a guide to keep in mind until upstreams are as principled as we are 😄

cc @Ericson2314

Metadata

Metadata

Assignees

Labels

6.topic: cross-compilationBuilding packages on a different platform than they will be used on6.topic: haskellGeneral-purpose, statically typed, purely functional programming language

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions