#738: Recompiling the same library version can change its ABI, causing breakage (even of Cabal) ----------------------------+----------------------------------------------- Reporter: Blaisorblade | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.4 Severity: major | Keywords: Difficulty: unknown | Ghcversion: 6.10.4 Platform: | ----------------------------+----------------------------------------------- On my system, cabal recompiled a package on which Cabal itself depended, breaking the linking of Setup.hs when trying to update new packages. My problem was partially due to an upgrade of a "core package" (on which cabal depends): install of core packages should be refused, for the same reason that "cabal upgrade" is disabled. But that's a side issue, probably known. Recompiling a non-core package could break silently another non-core package, in the same way. The root problem, IMHO, stems from handling of dependencies. Compiler-generated identifiers are exported, due to cross- module linking, and they depend from used modules and options about compilation (especially optimization). It thus seems that the ABI of a module is a (pure) function of the versions of all its (transitive) dependencies, and their compilation options - in particular, the optimization options and the used compiler version. Surely, the ABI does not depend just on the package version. More formally, my conjecture is: - let us represent "package a depends on b" as "a =>> b", where a, b are package names tagged with a version - let =>>* be the transitive-reflexive closure of =>> we need to compute: DEPS(p) = {q | p =>>* q } TAGGED_DEPS(p) = { (q, compilation_opts(q)) | q \in DEPS(p) } where compilation_opts(q) are the compilation options used to compile package q. Then, the ABI of package p is a pure function of TAGGED_DEPS(p), not just of p. My experience proves at least that the ABI does not depend just on p. Possibly, a package ABI depends on the build ID, if internally generated identifiers are random, but it does not look like that on my system (they are sequentially generated). Finally, there should be a way to automatically recompile dependent packages, as in Gentoo's revdep-rebuild. In my case, I wasn't prevented by ghc-pkg from removing a package on which other packages depended, while it does do some dependency tracking. Further info is being discussed on Haskell-cafe in this thread: http://groups.google.com/group/haskell- cafe/browse_thread/thread/838f2c098941bac9 Software versions: cabal-install version 0.8.2 using version 1.8.0.6 of the Cabal library (installed through Hackage, not available in this bug report form under "version"). GHC 6.10.4 -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/738 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects