Build failures in packages built with GHC 6.6
Hi folks, Over the weekend Lennart Kolmodin tested all of Gentoo's Haskell packages with the latest GHC 6.6 RC snapshot. Here is his report of what failed, and how: http://www.haskell.org/~gentoo/gentoo-haskell/projects/GHC-6.5-failures.html You'll note that there are some common ones, like Data.FiniteMap going away and the old API in Data.Set disappearing. There seemed to be several programs which used the old lang or text packages. The change in the array bounds api broke some things. Text.Regex moved into a different package. Most of these look fairly trivial. Class instance changes broke a couple packages, which might be a bit more tricky to fix. One Cabal api change broke one package, again easily fixable. We made some Cabal modules that had been private by convention properly private (ei Distribution.Compat.*). This broke lhs2tex. I'm not sure exactly what Cabal scripts should be using for portable file path handling since Setup.hs modules are not supposed to have external dependencies on other packages (otherwise there's a chicken and egg problem with compiling Setup.hs). Advice here would be apreciated, I could let Distribution.Compat.FilePath remain public in this release and seek a better solution for the next release. BTW, you can see the complete set of Gentoo's Haskell packages here: http://www.haskell.org/~gentoo/gentoo-haskell/ (mostly under dev-haskell/) Gentoo users & developers can use this package collection as a portage overlay. Duncan (wearing his Cabal release manager hat and his Gentoo hat)
Over the weekend Lennart Kolmodin tested all of Gentoo's Haskell packages with the latest GHC 6.6 RC snapshot. Here is his report of what failed, and how:
Thanks for the useful heads-up - a very valuable service. To fix HaXml to work with ghc-6.6, I have pushed two new versions: 1.17 is the development branch, and 1.13.2 is the stable branch. 1.13.2: http://www.haskell.org/HaXml 1.17: http://www.cs.york.ac.uk/fp/HaXml-devel Hopefully this will enable some other packages to build now as well. I note hmake's failure, and have pushed a possible fix to the darcs repo, but will not make a release until I have tested it more thoroughly. Regards, Malcolm
Niklas Broberg patched haskell-src-exts so it should work using the
latest version from darcs.
On 9/11/06, Duncan Coutts
Hi folks,
Over the weekend Lennart Kolmodin tested all of Gentoo's Haskell packages with the latest GHC 6.6 RC snapshot. Here is his report of what failed, and how:
http://www.haskell.org/~gentoo/gentoo-haskell/projects/GHC-6.5-failures.html
You'll note that there are some common ones, like Data.FiniteMap going away and the old API in Data.Set disappearing. There seemed to be several programs which used the old lang or text packages. The change in the array bounds api broke some things. Text.Regex moved into a different package. Most of these look fairly trivial. Class instance changes broke a couple packages, which might be a bit more tricky to fix.
One Cabal api change broke one package, again easily fixable. We made some Cabal modules that had been private by convention properly private (ei Distribution.Compat.*). This broke lhs2tex. I'm not sure exactly what Cabal scripts should be using for portable file path handling since Setup.hs modules are not supposed to have external dependencies on other packages (otherwise there's a chicken and egg problem with compiling Setup.hs).
Advice here would be apreciated, I could let Distribution.Compat.FilePath remain public in this release and seek a better solution for the next release.
BTW, you can see the complete set of Gentoo's Haskell packages here: http://www.haskell.org/~gentoo/gentoo-haskell/ (mostly under dev-haskell/) Gentoo users & developers can use this package collection as a portage overlay.
Duncan (wearing his Cabal release manager hat and his Gentoo hat)
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
On Mon, 2006-09-11 at 13:24 +0200, Johan Tibell wrote:
Niklas Broberg patched haskell-src-exts so it should work using the latest version from darcs.
That's great. Do you know if there will be a release with a tarball? Generally distros only package released versions. Alternatively if the changes are not that big then we can apply a patch to the current released version. Duncan
Niklas Broberg patched haskell-src-exts so it should work using the latest version from darcs.
That's great.
Do you know if there will be a release with a tarball? Generally distros only package released versions. Alternatively if the changes are not that big then we can apply a patch to the current released version.
He didn't mention a tarball. The reason IIRC was a name clash between functions so he probably (although someone should check the patch to make sure this is the case) just qualified some function names. If so we can apply the patch to the current version. - Johan
Hi Duncan,
On Mon, 11 Sep 2006 17:34:26 +0900, Duncan Coutts
Over the weekend Lennart Kolmodin tested all of Gentoo's Haskell packages with the latest GHC 6.6 RC snapshot. Here is his report of what failed, and how:
http://www.haskell.org/~gentoo/gentoo-haskell/projects/GHC-6.5-failures.html
2006-09-12, Packages failing with GHC 6.5:
wx/src/Graphics/UI/WX/Types.hs:94:0: Bad interface file: out/wx/imports/Graphics/UI/WXCore/Types.hi Something is amiss; requested module wx:Graphics.UI.WXCore.Types differs from name found in the interface file wxcore:Graphics.UI.WXCore.Types
This is tricky. The wx package needs to be registered locally before anything else can be built against it.
This error comes from Generalise Package Support. http://www.haskell.org/pipermail/cvs-ghc/2006-July/030207.html So the wxcore package needs to be registered locally before building the wx package's module, the wx package doesn't need to be registered. See wxhaskell's Makefile definition : WXCORE-HCFLAGS =$(HCFLAGS) -fvia-C -package-name $(WXCORE) # build main library wxcore: wxc wxd wxcore-dirs $(WXCORE-LIBS) (snip) WX-HCFLAGS =$(HCFLAGS) -fvia-C -package-name $(WX) WX-HSDIRS =-i$(WX-SRCDIR) $(WXCORE-HSDIRS) # build main library wx: wxcore wx-dirs $(WX-LIBS) ... The wx package wants to use its package's module when dependecies is built same time. But that is build as wxcore's by -package-name option. Then above error is caused. Unfortunately, Generised Package's Support is used just internally. Because syntax is proposal now. http://www.mail-archive.com/haskell@haskell.org/msg18991.html http://hackage.haskell.org/trac/ghc/wiki/GhcPackages http://hackage.haskell.org/trac/ghc/wiki/GhcPackageNamespaces So we have only two way. 1. The wxcore package needs to be registered locally before building the wx package's module. It is alredy written above. 2. The wx package needs to build and install separately from wxcore by Cabal .... But it makes install step more complex, that is bad for Windows and Mac OS User. But both ways are big change. P.S. Don't forgot this change to use wxhaskell with GHC 6.6. http://www.haskell.org/pipermail/glasgow-haskell-bugs/2005-October/005639.ht... -- shelarcy <shelarcy capella.freemail.ne.jp> http://page.freett.com/shelarcy/
participants (4)
-
Duncan Coutts -
Johan Tibell -
Malcolm Wallace -
shelarcy