Yes, the module overlap restriction has started to bite us. It now turns out that you can't build GHC from CVS if you have wxHaskell installed. Why? Because wxHaskell depends on some older non-hierarchical packages (util in particular, which itself depends on lang). These package populate the top-level module namespace, and steal a bunch of module names that you might want to use in your program. In fact, GHC itself contains a module with the same name as one in the lang package: Generics. The error is real - if we *had* imported something from wxHaskell, then the program would contain two modules called Generics, and since the linker's name space is global, mayhem would ensue. Because we're doing separate compilation, GHC can't tell that we haven't actually imported anything from wxHaskell, so it has to be conservative and assume that we will. New GHCs are a bit stricter about complaining about duplicate modules, with the result that GHC fails to build. We know the reasons for this - they were all discussed at length in a recent thread. What can we do? 1. Package builders should be careful about dependencies. Don't depend on any non-hierarchical packages from an exposed package. Daan - can you fix wxHaskell? 2. The GHC build could start using -fignore-all-packages to insulate itself from the environment (or, simpler but more hacky: -ignore-package lang). This isn't a *solution* as such, because the problem affects everyone, not just us. 3. We could put some safeguards in place to avoid this happening in the future, e.g. warnings from Cabal and/or ghc-pkg. 4. Cabal needs to start using -fignore-all-packages. Isaac? Thoughts? Cheers, Simon