You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
InBetweenNames
changed the title
cabal should factor the libc used to build a package into the hash of the package
Cabal should factor the libc used to build a package into the hash of the package
Mar 28, 2020
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.
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.
The text was updated successfully, but these errors were encountered: