[Haskell-cafe] Upgrading ByteString causes (seemingly) impossible RTS linker errs

[Austin Seipp]

Recently I've been developing my IRC bot a little further, and in the
midst of it I have come across a very problematic issue that revolves
around GHC-dependencies vs. application-dependencies. The central issue
is ByteString.

Currently, the ghc package depends on bytestring-0.9.0.1. However, the
current version of ByteString I have installed is 0.9.0.4. To keep
compatability with bytestring-dependent libraries that were built
against 0.9.0.1, you have to recompile of all these libs against
0.9.0.4. For example, I had to build a newer version of zlib against
0.9.0.4, because the older version was built for 0.9.0.1, which mean
that it was not possible to build cabal-install because of the
incompatabilities (it needed bytestring and zlib.)

The problem is that if you have a package that depends on ghc as a
library, but also depends on bytestring > 0.9.0.1 or any library built
against it, you'll get pretty much unstoppable linker errs, since all the
symbol names in the ghc package are hardwired for 0.9.0.1 (meaning you
can't do 'ghc-pkg update' for it) forcing it to be loaded.

The example in my bot is this: it depends on binary which is built
against bytestring-0.9.0.4 for serializing the state of plugins. If you
configure it with the flag '-fdynamic' and you have hs-plugins for ghc
6.8 installed (http://code.haskell.org/~dons/code/hs-plugins/) then the
bot can do in-situ code reloading.

However, hs-plugins depends on ghc as a library, which depends on
bytestring 0.9.0.1... I think you can see where this is going (actually
I can't quite pinpoint it to being hs-plugins importing ghc since, but
essentially it could be *any* lib my bot uses which depends on ghc as a
library, hs-plugins is just the most obvious one):

[austin at continuum 0.4]$ ghci Setup.hs 
GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
Loading package base ... linking ... done.
...
*Main> :main configure  
Loading package array-0.1.0.0 ... linking ... done.
Loading package packedstring-0.1.0.0 ... linking ... done.
Loading package containers-0.1.0.1 ... linking ... done.
Loading package old-locale-1.0.0.0 ... linking ... done.
Loading package old-time-1.0.0.0 ... linking ... done.
Loading package filepath-1.1.0.0 ... linking ... done.
Loading package directory-1.0.0.0 ... linking ... done.
Loading package unix-2.3.0.0 ... linking ... done.
Loading package process-1.0.0.0 ... linking ... done.
Loading package pretty-1.0.0.0 ... linking ... done.
Loading package hpc-0.5.0.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package readline-1.0.1.0 ... linking ... done.
Loading package Cabal-1.2.3.0 ... linking ... done.
Loading package random-1.0.0.0 ... linking ... done.
Loading package haskell98 ... linking ... done.
Loading package parsec-2.1.0.0 ... linking ... done.
Loading package haskell-src-1.0.1.1 ... linking ... done.
Loading package network-2.1.0.0 ... linking ... done.
Loading package mtl-1.1.0.0 ... linking ... done.
Loading package stm-2.1.1.0 ... linking ... done.
Loading package irc-0.4 ... linking ... done.
Loading package QuickCheck-2.0 ... linking ... done.
Loading package bytestring-0.9.0.4 ... linking ... done. <-- needed for binary
Loading package binary-0.4.1 ... linking ... done.
Loading package bytestring-0.9.0.1 ...                   <-- needed for ghc

GHCi runtime linker: fatal error: I found a duplicate definition for symbol
   fps_maximum
whilst processing object file
   /usr/local/lib/ghc-6.8.2/lib/bytestring-0.9.0.1/HSbytestring-0.9.0.1.o
This could be caused by:
   * Loading two different object files which export the same symbol
   * Specifying the same object file twice on the GHCi command line
   * An incorrect `package.conf' entry, causing some object to be
     loaded twice.
GHCi cannot safely continue in this situation.  Exiting now.  Sorry.

[austin at continuum 0.4]$

>From speculation, I would think that any package that uses ghc as a
library but also uses bytestring > 0.9.0.1, directly or indirectly,
would hit this error.

Is there any easy way to resolve this? From the looks of it, the *only*
way would really be to just unregister 0.9.0.4, and rebuild everything
against 0.9.0.1... Either that or factor out the use of ByteString in
the ghc-frontend. Neither seems optimal, though. But I've been
working on this too long to just stop, so if it requires recompiling
everything against an older version of bytestring, then so be it, I
suppose... Thanks for whoever helps.

- Austin

-- 
"It was in the days of the rains that their prayers went up, 
not from the fingering of knotted prayer cords or the spinning 
of prayer wheels, but from the great pray-machine in the
monastery of Ratri, goddess of the Night."
 Roger Zelazny