Here's are some relevant blocks of code:

I take it you are using the binary USE flag?

I'm not sure if amd64 and amd64-musl need to be treated as separate build hosts, e.g. musl needs its own binary.

@thesamesam might have some insight here.

dev-lang/ghc-9.0.2-r2 does not compile on Musl (no lib64)

@Thymelizabeth are you aware that using the binary USE flag skips compilation, and instead just installs directly from the binary we provide?

The way I see it, there are several problems with trying to install GHC on a system using musl:

1. The only binaries downloaded are compiled for glibc. These cannot be used to build GHC and cannot be installed directly to the system. Despite this, Portage sees no problem trying to install GHC on a musl based system. There is a build for Alpine Linux available from the main Haskell website which could be added. I recently changed the dev-dotnet/dotnet-sdk-bin package to change the binary download depending on the libc the system uses. This ebuild could use something similar.

2. When not using the binary USE flag, Portage tries to rename a non-existent folder, i.e. the /usr/lib folder to /usr/lib64. This folder is not provided in the binary. It is, however, provided in the source. /usr/lib64 already exists in the binary. musl does not recommend using a lib64 or lib32 directory

3. When trying to install with the binary USE flag, Portage tries to backup the /usr/lib/ghc-9.0.2/package.conf.d directory. This folder is also not provided in the binary package, and is not produced as the ebuild is processed. Bear in mind, this binary package is not compiled for musl, but Portage sees nothing wrong with trying to install it.

Thanks for your thoughts on this. I did not see that relocate_ghc is also called here, which is called when the binary USE flag is disabled, which disproves my assumption that you must have it enabled to hit this bug:

I don't have a lot of familiarity with the ghc ebuild or musl, unfortunately, but I can get a musl sandbox set up at some point to help with development.

@Thymelizabeth Do you think that something like this would be a good first step, just to ensure people on musl don't try to download our glibc binary?

diff --git a/dev-lang/ghc/ghc-9.0.2-r2.ebuild b/dev-lang/ghc/ghc-9.0.2-r2.ebuild
index 1bbe52e971..9e6149913c 100644
--- a/dev-lang/ghc/ghc-9.0.2-r2.ebuild
+++ b/dev-lang/ghc/ghc-9.0.2-r2.ebuild
@@ -29,7 +29,8 @@ BIN_PV=${PV}
 #arch_binaries="$arch_binaries alpha? ( https://slyfox.uni.cx/~slyfox/distfiles/ghc-bin-${PV}-alpha.tbz2 )"
 #arch_binaries="$arch_binaries arm? ( https://slyfox.uni.cx/~slyfox/distfiles/ghc-bin-${PV}-armv7a-hardfloat-linux-gnueabi.tbz2 )"
 #arch_binaries="$arch_binaries arm64? ( https://slyfox.uni.cx/~slyfox/distfiles/ghc-bin-${PV}-aarch64-unknown-linux-gnu.tbz2 )"
-arch_binaries="$arch_binaries amd64? ( https://eidetic.codes/ghc-bin-${PV}-x86_64-pc-linux-gnu-r1.tbz2 )"
+arch_binaries="$arch_binaries amd64? ( elibc_glibc? ( https://eidetic.codes/ghc-bin-${PV}-x86_64-pc-linux-gnu-r1.tbz2 ) )"
+#arch_binaries="$arch_binaries amd64? ( elibc_musl? ( https://eidetic.codes/ghc-bin-${PV}-x86_64-pc-linux-musl-r1.tbz2 ) )"
 #arch_binaries="$arch_binaries ia64?  ( https://slyfox.uni.cx/~slyfox/distfiles/ghc-bin-${PV}-ia64-fixed-fiw.tbz2 )"
 #arch_binaries="$arch_binaries ppc? ( https://slyfox.uni.cx/~slyfox/distfiles/ghc-bin-${PV}-ppc.tbz2 )"
 #arch_binaries="$arch_binaries ppc64? ( https://slyfox.uni.cx/~slyfox/distfiles/ghc-bin-${PV}-ppc64.tbz2 )"
@@ -46,7 +47,15 @@ yet_binary() {
                #alpha) return 0 ;;
                #arm64) return 0 ;;
                #arm) return 0 ;;
-               amd64) return 0 ;;
+               amd64)
+                       if use elibc_glibc; then
+                               return 0
+                       elif use elibc_musl; then
+                               return 1
+                       else
+                               return 1
+                       fi
+                       ;;
                #ia64) return 0 ;;
                #ppc) return 0 ;;
                ppc64)

Also, have you been able to build successfully with the ghcbootstrap USE flag using an instance of GHC installed through e.g. ghcup (or the alpine linux tarball)?

The patch looks good.

I tried installing with ghcbootstrap enabled, (using Another binary installed to /usr/local), but got a segmentation fault when make tried to use a non-existent file.
ghcbootstrap-enabled-build.log

Trying with the Alpine binary (9.0.2) from haskell.org gives the same result.

GHCup also segfaults.
ghcup-make.log
Unrelated issue: gold (binutils) has a bug where dynamically linked executables with musl segfault on startup, so I used lld with ghcup.

I'm not sure if amd64 and amd64-musl need to be treated as separate build hosts, e.g. musl needs its own binary.

@thesamesam might have some insight here.

Yeah, musl will always need its own set as it's a different ABI (treat it like a different architecture for the purposes of reusing binaries).

GHCup also segfaults. ghcup-make.log Unrelated issue: gold (binutils) has a bug where dynamically linked executables with musl segfault on startup, so I used lld with ghcup.

I would not use gold for anything, it's considered deprecated. The normal linker from GNU binutils (bfd) is fine, but gold is not.

I suggest taking a look here:
https://github.com/clang-musl-overlay/clang-musl-overlay/tree/master/dev-lang/ghc
I use this ebuild on musl and it works fine