[Haskell-cafe] Announce: bytestring 0.9.1.0

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Sun Apr 20 20:27:20 EDT 2008


On Sun, 2008-04-20 at 19:05 -0500, Austin Seipp wrote:
> > That's all good news; will this release of ByteString be used for GHC 6.8.3?
> > I'm a little tired of linking everything against 0.9.0.1 just so I can use Yi
> > (since GHC/the-GHC-API links against it). :)
> 
> Indeed; this is the biggest issue I have with bytestring right now as
> it's interfered with my work with hs-plugins/GHC-api, especially
> considering I think the new cabal and ghc 6.8.3 should fix or at least
> warn about the library-version-mismatch issues (from what I've heard.)

Cabal-1.4 does warn at configure time if a build is going to use
inconsistent versions of dependent libraries. Trying to come up with an
installation plan that avoids the problem is a good deal harder and in
general isn't possible without having to rebuild lots of unrelated
packages.

> The only probable fix I can think of (other than doing compile-time
> hackery on both the C and haskell side to make symbol names differ
> across releases,

All haskell code does work this way, ghc puts the package name and
version into the symbol name so it is possible to link several versions
of a package into one program. The particular problem for bytestring is
the C code that it uses. So while Data.ByteString.foo get's mapped to a
symbol name something like "bytestring_0_9_1_0_DatazByteStringzfoo" the
embedded C code gets no such mangling so fps_reverse from
bytestring-0.9.0.1 clashes with fps_reverse from bytestring-0.9.0.4.

Actually the gnu ld linker doesn't mind about the duplicate symbols and
just picks ones of them. The ghci linker is a bit more paranoid and
rejects the duplicates. I guess we could try and adjust the names of the
C symbols to include the package name and version.

Duncan



More information about the Haskell-Cafe mailing list