From speculation, I would think that any package that uses ghc as a
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@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@continuum 0.4]$ 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