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 _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
