Fix the platform string for GNU/Hurd

[sthibaul]

Since version 9.4.7-1, ghc fails to build on the GNU/Hurd port of Debian, see

https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=hurd-i386&ver=9.4.7-1&stamp=1697717885&raw=0

Error, rule finished running but did not produce file:
  _build/stage0/lib/i386-gnu-ghc-9.4.6/ghc-boot-th-9.4.7/libHSghc-boot-th-9.4.7.a

and indeed, what did get produce was rather
_build/stage0/lib/i386-hurd-ghc-9.4.6/ghc-boot-th-9.4.7/libHSghc-boot-th-9.4.7.a (i386-hurd instead of i386-gnu).

This is due to confusion between hurd and gnu in various places. Apparently previous versions of ghc were using gnu for the GNU/Hurd port, and thus putting libraries etc. in i386-gnu. So we have to follow the existing practice.

[ffaf1]

cabal/Cabal-syntax/src/Distribution/System.hs

Lines 145 to 156 in 69417ac

	osAliases :: ClassificationStrictness -> OS -> [String]
	osAliases Permissive Windows = ["mingw32", "win32", "cygwin32"]
	osAliases Compat Windows = ["mingw32", "win32"]
	osAliases _ OSX = ["darwin"]
	osAliases _ Hurd = ["gnu"]
	osAliases Permissive FreeBSD = ["kfreebsdgnu"]
	osAliases Compat FreeBSD = ["kfreebsdgnu"]
	osAliases Permissive Solaris = ["solaris2"]
	osAliases Compat Solaris = ["solaris2"]
	osAliases Permissive Android = ["linux-android", "linux-androideabi", "linux-androideabihf"]
	osAliases Compat Android = ["linux-android"]
	osAliases _ _ = []

I wonder whether this string should be changed too.

Edit: of course not, since it is correct.

[ulysses4ever]

This PR looks like it tries to work around a problem with older GHCs (9.4.6 and previous, which all use "gnu" for GNU/Hurd). I'm not sure this is the direction we should go. Maybe we should rather strive to support newer GHCs in cabal's master branch?

[ffaf1]

Relevant gnu/hurd mentions I found in GHC codebase:

• fptools_set_haskell_platform_vars.m4
• ParseTriple.hs
• ArchOS.hs

[sthibaul]

This PR looks like it tries to work around a problem with older GHCs (9.4.6 and previous, which all use "gnu" for GNU/Hurd). I'm not sure this is the direction we should go. Maybe we should rather strive to support newer GHCs in cabal's master branch?

Well, I'm fine with whatever you prefer, we "just" need a migration path. ATM I can't build debian's ghc 9.4.7 unpatched using debian's ghc 9.4.6, because the state is incoherent for now, the proposed fix is needed to get things coherent.

[Mikolaj]

Well, I'm fine with whatever you prefer, we "just" need a migration path. ATM I can't build debian's ghc 9.4.7 unpatched using debian's ghc 9.4.6, because the state is incoherent for now, the proposed fix is needed to get things coherent.

And you can't jump to 9.6.3 (assuming it's fixed there)? {Edit: or wait for 9.4.8, assuming it will be fixed there?]

[sthibaul]

And you can't jump to 9.6.3 (assuming it's fixed there)? {Edit: or wait for 9.4.8, assuming it will be fixed there?]

I can wait for 9.4.8, or build a patched 9.4.7, yes, but I don't understand what this changes in the problem. Perhaps what I don't actually understand is this:

Maybe we should rather strive to support newer GHCs in cabal's master branch?

What do you mean by "newer" exactly? AIUI nothing has changed in ghc itself, it's just that as of its version 9.4.7-1 of the ghc packaging, debian started to use hadrian to build ghc packages, which probably changed which codepath actually does building/linking/installing, and AIUI it just happens that the codepath newly triggered has actually just always been bogus, and we just never noticed because it was never exercised. Thus why I'm here just proposing to fix it.

[Mikolaj]

Oh, so it's not a bug in GHC? [Edit: Meaning also the GHC build toolset.]

[ulysses4ever]

Another way to put my concern is that if this patch had

ghcOsString Hurd = "hurd"

instead of what it currently has, I'd support it with no doubt.

[sthibaul]

Oh, so it's not a bug in GHC? [Edit: Meaning also the GHC build toolset.]

It has always be so in GHC.

Another way to put my concern is that if this patch had

ghcOsString Hurd = "hurd"

instead of what it currently has, I'd support it with no doubt.

It would be useless then... The whole point of these lines is when the two parts don't actually match.

Put another way: in GHC's m4/ghc_convert_os_m4:

      gnu*) # e.g. i686-unknown-gnu0.9
        $3="gnu"
        ;;

is what matches the GNU/Hurd OS. Yes, a mere "gnu", because it's the pure-GNU OS as was planned by FSF decades ago. That's why various software call it just "gnu", when others prefer to all it "hurd", thus the confusing difference here.

Which is exactly the same kind of confusing terms as the other lines above the line I propose to change: depending who you ask, windows will rather be called mingw32, OS X will be called Darwin, Solaris will be called Solaris2. Those are exactly what GHC's m4/ghc_convert_os_m4 matches, thus why I'm proposing to just follow what is already done for those.

[sthibaul]

in GHC's m4/ghc_convert_os_m4:

 gnu*) # e.g. i686-unknown-gnu0.9
   $3="gnu"
   ;;

Put another way: autotools etc. call it "gnu", so I guess that's why the ghc port kept that name, so that ghc libraries get installed in i386-gnu-*, just like they are installed in i386-gnu by autotools etc. Turning that into i386-hurd could be more confusing when looking at the filesystem.

Another way would be to rename all "Hurd" occurrences in GHC into Gnu, but that would also bring confusion, this time to source readers, wondering whether it's GNU meaning GNU/Linux.

Thus why this correspondance, exactly like Windows is not really "mingw32", OSX is not really "darwin", Solaris is not only "solaris2", but it makes sense to keep both names and keep these lines to make the matching between the two.

[sthibaul]

Oh, so it's not a bug in GHC? [Edit: Meaning also the GHC build toolset.]

It has always be so in GHC.

And things have not changed in GHC. It's just the Debian packaging that started using a different toolset, that seems not to know about the discrepancy between hurd and gnu.

[Mikolaj]

That's clarified for me now. Thank you.

[Mikolaj]

BTW, when you are ready, please remove the needs-review label and add one of the merge labels, as explained in CONTRIBUTING.

[Mikolaj]

Oh, and a changelog entry would be very welcome.

[Mikolaj]

Thank you very much!