Open InBetweenNames opened 4 years ago
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)?
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.
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?
I suppose the issue would be linked here if anybody did, so probably not. I haven't searched the GHC bug tracker, though.
Describe the bug Right now,
cabal-install
will place all packages in the package cache ordist-newstyle
underbuild/<arch>
, for examplebuild/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/
. (likecryptonite-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:
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
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.