# [Hackage] #738: Recompiling the same library version can change its ABI, causing breakage (even of Cabal)

Sun Sep 12 13:06:53 EDT 2010

#738: Recompiling the same library version can change its ABI, causing breakage
(even of Cabal)
----------------------------+-----------------------------------------------
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-
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.

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

--