Bug#910664: Acknowledgement (ghc: ghc package can no longer be cross-compiled)

[Ilias Tsitsimpis]

Hi Helmut,

On Sun, Dec 10, 2023 at 09:01PM, Helmut Grohne wrote:
> First and foremost, ghc now actively refuses being cross build with an
> $(error ...). Would you mind weakening this to a $(warning ...)? While
> that you don't want to support cross building of ghc, would you mind
> others (like me) supporting it? Yes, it would still fail, but then
> https://crossqa.debian.net/src/ghc could show a more useful reason for
> that failure.

The reason I have this as an $(error ...) is because the new Hadrian
build system doesn't support cross-compiling GHC [1]. This is not a
limitation of our Debianization (i.e., it's not that we refuse to
cross-build GHC, we *cannot* cross-build GHC), this is upstream
limitation. Given that, I believe $(error ...) is more appropriate here
than $(warning ...).

[1] https://gitlab.haskell.org/ghc/ghc/-/issues/23975

> Then when you get past the $(error ...), stage1 tools are not found. In
> a cross build, ghc prefixes these with the host gnu triplet. A bit of
> renaming is required to make this work. (patch attached)

The resulting stage1 tools are a cross-compiler, not the final
cross-compiled binaries (this is why they are prefixed with the host gnu
triplet). I am not sure how we will handle this, I am waiting to see on
what upstream will do to support cross-building GHC. For now, I believe
applying the attached patch doesn't help.

> And then we run into:
> 
> On Tue, Oct 09, 2018 at 03:24:41PM +0200, John Paul Adrian Glaubitz wrote:
> > This change to the debian/rules file helps to get a bit further:
> > 
> > --- debian/rules.orig   2018-09-26 11:08:46.000000000 +0200
> > +++ debian/rules        2018-10-09 15:22:43.080942145 +0200
> > @@ -126,6 +126,7 @@
> >         echo 'V=1'                                     >> mk/build.mk
> >         dh_auto_configure -- \
> >                 $(EXTRA_CONFIGURE_FLAGS) \
> > +               --host=$(DEB_BUILD_GNU_TYPE) \
> >                 --with-system-libffi --libdir=/usr/lib
> >  
> >  override_dh_auto_build:
> > 
> > But it will still fail with:
> 
> I think this is wrong. The current ghc packaging includes this flag, but
> ghc uses the same terminology as Debian, so when we say
> --host=$(DEB_BUILD_GNU_TYPE) we ask it to produce a cross compiler, but
> we really wanted a cross built ghc. One of the issues referenced from
> the earlier $(error ...) also hints that this value is wrong for --host:
> https://gitlab.haskell.org/ghc/ghc/-/issues/22006 Unless you have strong
> reasons for why that should be correct, I suggest that we change it to
> --host=$(DEB_HOST_GNU_TYPE). (not included in patch)

GHC does *not* use the same terminology as Debian. GHC requires that
HOST and BUILD are the same. You can read more about this here [2],
though keep in mind this document is severely outdated with the Hadrian
build system.

[2] https://gitlab.haskell.org/ghc/ghc/-/wikis/building/cross-compiling#terminology-and-background

> So this is where we are. I think we can make progress here if you want
> to support this work. I'm also a big fan of actionable bug reports and
> in having a patch, this bug becomes actionable. Given that you (ghc
> maintainers) are evidently not interested in doing the work here, I also
> suggest that you close this bug when applying the patch and letting
> cross users file new bugs with new patches. Let me know what you think
> about this.

I believe we need to work with upstream to add support for
cross-compiling GHC to the new Hadrian build system. As explained here [3],
this is currently not possible. I tested everything I could think of,
but I don't see how we can move forward without reworking how the
Hadrian build system works. Upstream has started working on this, but
it's moving slowly [4].

In summary, as a result of the switch to the Hadrian build system, we
are now unable to cross-compile GHC. Since this issue now has all the
latest context, I propose we keep it open and work here on
cross-building GHC.

[3] https://gitlab.haskell.org/ghc/ghc/-/issues/23975#note_526546
[4] https://gitlab.haskell.org/ghc/ghc/-/issues/23975#note_530201

Thanks,

-- 
Ilias