Skip to content

Build path leaks into ABI hashes

The build path of GHC leaks into the ABI hashes, i.e. if you build GHC in /tmp/fooADDF and then in /tmp/fooSDFS, you get different ABI hashes. This is a serious problem for distributions, as it means that we cannot rebuild the GHC package without rebuilding all Haskell packages as well.

The (or at least one) problem is include paths. We have

include-dirs: /home/jojo/build/haskell/ghc/rts/dist/build
              /home/jojo/build/haskell/ghc/includes
              /home/jojo/build/haskell/ghc/includes/dist-derivedconstants/header

in inplace/lib/package.conf.d/builtin_rts.conf, so when running the preprocessor, GHC passes this full path to the preprocessor:

/usr/bin/gcc -E -undef -traditional -DOPTIMISE_INTEGER_GCD_LCM -include libraries/base/dist-install/build/autogen/cabal_macros.h -I libraries/base/dist-install/build -I libraries/base/dist-install/build -I libraries/base/dist-install/build/autogen -I libraries/base/include -I /home/jojo/build/haskell/ghc/libraries/integer-gmp/include -I /home/jojo/build/haskell/ghc/rts/dist/build -I /home/jojo/build/haskell/ghc/includes -I /home/jojo/build/haskell/ghc/includes/dist-derivedconstants/header '-D__GLASGOW_HASKELL__=711' -include /home/jojo/build/haskell/ghc/includes/ghcversion.h '-Dlinux_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dlinux_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp libraries/base/System/Info.hs -o /tmp/ghc14804_0/ghc14804_1.hscpp

It then reads the included files from the hscpp file :

$ grep home /tmp/ghc14830_0/ghc14830_1.hscpp
# 1 "/home/jojo/build/haskell/ghc/includes/ghcversion.h" 1
# 1 "/home/jojo/build/haskell/ghc/includes/ghcplatform.h" 1

and puts it into the interface, where it becomes part of the hash:

$ ./inplace/bin/ghc-stage1 --show-iface ./libraries/base/dist-install/build/System/Info.hi |grep Dep
addDependentFile "/home/jojo/build/haskell/ghc/includes/ghcplatform.h"
addDependentFile "/home/jojo/build/haskell/ghc/includes/ghcversion.h"
addDependentFile "libraries/base/dist-install/build/autogen/cabal_macros.h"
addDependentFile "/usr/include/stdc-predef.h"

Clearly, the end result is undesirable (changing hashes due to path names) and actually useless, as the build path will not be there later anyways.

I’m not sure what the best way to fix this is. Here are a few ideas:

  • Do not include the path of addDependentFile entries in the hash, but only the file hash. Should solve the ABI hash.
  • Use relative paths in inplace/lib/package.conf.d/builtin_rts.conf. Not sure what breaks.

This bug appeared in 7.8.4 and is present in both 7.10 and current HEAD.

Any other ideas?

(Debian bugreport at http://bugs.debian.org/785282)

Trac metadata
Trac field Value
Version 7.8.4
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information