Upgrading ByteString causes (seemingly) impossible RTS linker errs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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@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]$

>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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Upgrading ByteString causes (seemingly) impossible RTS linker errs

Don Stewart-2
mad.one:

> 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.

It should be possible to specify that your lib depends on exactly
0.9.0.1 in the .cabal file.

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Upgrading ByteString causes (seemingly) impossible RTS linker errs

Adam Langley-2
On Jan 27, 2008 12:24 PM, Don Stewart <[hidden email]> wrote:
> It should be possible to specify that your lib depends on exactly
> 0.9.0.1 in the .cabal file.

In the same general area. When you upgrade something like bytestring
and have to update everything that was built with it (otherwise you'll
get type errors because the ByteString types from the two different
versions are different) cabal-install is of no help. Since it already
believes that I have those packages installed (correctly) if refuses
to install them again so I have to do it all by hand.

I realise that I should be sending darcs patches, not bug reports, but
a --force to reinstall an already installed package would be great. I
guess, ideally, cabal-install would know to rebuild everything that
depends on x when I upgrade x.

darcs patches might follow if I can get round to it (or the next time
I update bytestring...)

Cheers,


--
Adam Langley                                      [hidden email]
http://www.imperialviolet.org                       650-283-9641
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Upgrading ByteString causes (seemingly) impossible RTS linker errs

Duncan Coutts

On Sun, 2008-01-27 at 12:54 -0800, Adam Langley wrote:

> On Jan 27, 2008 12:24 PM, Don Stewart <[hidden email]> wrote:
> > It should be possible to specify that your lib depends on exactly
> > 0.9.0.1 in the .cabal file.
>
> In the same general area. When you upgrade something like bytestring
> and have to update everything that was built with it (otherwise you'll
> get type errors because the ByteString types from the two different
> versions are different) cabal-install is of no help. Since it already
> believes that I have those packages installed (correctly) if refuses
> to install them again so I have to do it all by hand.
>
> I realise that I should be sending darcs patches, not bug reports, but
> a --force to reinstall an already installed package would be great. I
> guess, ideally, cabal-install would know to rebuild everything that
> depends on x when I upgrade x.

This issue is filed as:

http://hackage.haskell.org/trac/hackage/ticket/220

> darcs patches might follow if I can get round to it (or the next time
> I update bytestring...)

Great. The first step is to take advantage of the new feature in ghc-pkg
in ghc-6.8.3 to enable us to get a complete database for all installed
packages, rather than just a list of package names and versions.

The following step would be to detect and warn about inconsistent
versions of deps.

The hardest part is integrating this constraint into the cabal-install
package search / dependency resolution algorithm, and if the constraint
turns out to be unsatisfiable, working out which packages have to be
rebuilt to get a consistent set of dependencies.

Of course in the case cited here we have to either make everything stick
with bytestring-0.9.0.1 or try and rebuild the ghc package against the
newer bytestring, but there is no .cabal package available for the ghc
package. In principle I think there could be, there just isn't at the
moment.

Duncan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe