Cabal should factor the libc used to build a package into the hash of the package

[InBetweenNames]

Describe the bug
Right now, cabal-install will place all packages in the package cache or dist-newstyle under build/<arch>, for example build/arm-linux. This works fine if there is only one libc you are targeting. If you have multiple devices with different libc's, but the same architecture, then what could happen is the wrong objects will be pulled in during the build.

For example, I have two routers that I deploy on right now, one with glibc and one with musl. If I build with glibc, then switch over to musl, the main project gets rebuilt but the dependencies don't -- and the glibc-targeted artifacts are pulled into my musl build. This usually results in undefined symbol errors at link time. To work around this, I just have to delete dist-newstyle/build/arm-linux and possibly a dependency or two in /home/shane/.cabal/store/ghc-8.10.1/. (like cryptonite-0.26, for example). That will trigger a rebuild with the correct libc targeted.

To Reproduce
Steps to reproduce the behavior:

The easiest way I can think of to reproduce this involves cross compiling with two different toolchains. On Gentoo here, I have a glibc-based ARM and musl-based ARM toolchain.

First, cross compile a package with the glibc toolchain:
cabal v2-build --allow-newer --with-ghc=armv7a-hardfloat-linux-gnueabi-ghc --with-hc-pkg=armv7a-hardfloat-linux-gnueabi-ghc-pkg

That ought to work fine. Now, cross compile a package with the musl toolchain:
cabal v2-build --allow-newer --with-ghc=armv7a-hardfloat-linux-musleabi-ghc --with-hc-pkg=armv7a-hardfloat-linux-musleabi-ghc-pkg

Now, you might start seeing compilation errors show up, like the following:

Build profile: -w ghc-8.10.1 -O1
In order, the following will be built (use -v for more details):
 - XSaiga-1.6.1.0 (exe:solarman.cgi) (first run)
Preprocessing executable 'solarman.cgi' for XSaiga-1.6.1.0..
Building executable 'solarman.cgi' for XSaiga-1.6.1.0..
Linking /home/shane/workspace/solarman/dist-newstyle/build/arm-linux/ghc-8.10.1/XSaiga-1.6.1.0/x/solarman.cgi/build/solarman.cgi/solarman.cgi ...
/usr/libexec/gcc/armv7a-hardfloat-linux-musleabi/ld: /home/shane/.cabal/store/ghc-8.10.1/cryptonite-0.26-4e3e0bae4fa156a6da0ea4473e9bd30a80d1012f8d556a47129b3812f6c941a7/lib/libHScryptonite-0.26-4e3e0bae4fa156a6da0ea4473e9bd30a80d1012f8d556a47129b3812f6c941a7.a(cryptonite_sha512.o): in function `cryptonite_sha512t_init':
cryptonite_sha512.c:(.text+0x147c): undefined reference to `__sprintf_chk'
/usr/libexec/gcc/armv7a-hardfloat-linux-musleabi/ld: /home/shane/.cabal/store/ghc-8.10.1/cryptonite-0.26-4e3e0bae4fa156a6da0ea4473e9bd30a80d1012f8d556a47129b3812f6c941a7/lib/libHScryptonite-0.26-4e3e0bae4fa156a6da0ea4473e9bd30a80d1012f8d556a47129b3812f6c941a7.a(ed25519.o): in function `expand256_modm':
ed25519.c:(.text+0x51c0): undefined reference to `__memcpy_chk'
/usr/libexec/gcc/armv7a-hardfloat-linux-musleabi/ld: /home/shane/.cabal/store/ghc-8.10.1/cryptonite-0.26-4e3e0bae4fa156a6da0ea4473e9bd30a80d1012f8d556a47129b3812f6c941a7/lib/libHScryptonite-0.26-4e3e0bae4fa156a6da0ea4473e9bd30a80d1012f8d556a47129b3812f6c941a7.a(cryptonite_sha3.o): in function `cryptonite_sha3_update':
cryptonite_sha3.c:(.text+0x274): undefined reference to `__memcpy_chk'
collect2: error: ld returned 1 exit status
`armv7a-hardfloat-linux-musleabi-gcc' failed in phase `Linker'. (Exit code: 1)

I suspect this may have to do with the fact that some libraries have C code which is built with FORTIFY_HEADERS, a glibc macro in this case. This causes the code to be linked against functions such as __memcpy_chk, which are glibc specific and don't exist in musl.

To work around this, all one has to do is, in this case, rm ~/.cabal/store/ghc-8.10.1/cryptonite-0.26-*, which will then trigger a rebuild of that package. It seems like the package hash doesn't take into account the libc used to build that package, and so it simply pulls in the wrong compiled package from the cache.

Expected behavior
Cabal should take into account the libc used to build a package and recognize that as the same as if the package flags itself had changed somehow (say, the toolchain changed, or debug symbols are requested, or a package specific flag changed, etc).

System information

• Gentoo, testing, GentooLTO configuration
• cabal git latest (3.3), ghc 8.10.1

Additional context
I realize that this might be a really esoteric thing, but it would make cross compiling with cabal easier. The package that I'm working on is XSaiga, which has a lot of different dependencies, but I could distill this into a minimal working example if needed.

[hvr]

How would cabal identify the ABI of the libc used (ideally in a way that doesn't trash whenever apt-get upgrade updates the libc in a backward compat way)?

[InBetweenNames]

That's a great question. Doing a bit more research on this, it seems that this may be a GHC issue rather than a Cabal issue specifically, as GHC defines the AbiHash and Cabal just passes information to that. GHC is probably in a better position to see which libc is in use than Cabal is.

[georgefst]

That's a great question. Doing a bit more research on this, it seems that this may be a GHC issue rather than a Cabal issue specifically, as GHC defines the AbiHash and Cabal just passes information to that. GHC is probably in a better position to see which libc is in use than Cabal is.

Did you ever open a GHC issue about this?

[Mikolaj]

I suppose the issue would be linked here if anybody did, so probably not. I haven't searched the GHC bug tracker, though.