
Hi Duncan, That works just fine: Installing library in /Users/briand/.cabal/lib/binary-0.5.0.2/ghc-6.10.1 Registering binary-0.5.0.2... Reading package info from "dist/installed-pkg-config" ... done. Writing new package config file... done. and still ghc gives me: Loading package binary-0.5.0.1 ... can't load .so/.DLL for: HSbinary-0.5.0.1 (dlopen(libHSbinary-0.5.0.1.dylib, 9): image not found) The question, of course, is to figure out why ghc is trying to load the old version. I know binary isn't dynamically linked, because ghc works unless I'm trying to use the binary package. Is there something broken in the 0.5.0.2 release that causes ghc to look for the old library ? Brian On Oct 28, 2009, at 4:00 AM, Duncan Coutts wrote:
On Tue, 2009-10-27 at 21:37 -0700, brian wrote:
It all started with this:
Loading package binary-0.5.0.1 ... can't load .so/.DLL for: HSbinary-0.5.0.1 (dlopen(libHSbinary-0.5.0.1.dylib, 9): image not found)
so I tried
cabal upgrade binary
Don't do that. Just use cabal install binary.
Upgrade means install the named package and also try to install the latest version of all of its dependencies. That's generally not a good idea. It's choosing to upgrade your containers package and you probably do not want to do that.
We're thinking about how to changing the behaviour of upgrade so that you can upgrade the dependencies you want without also upgrading the ones that you really wanted to be kept the same (like the core or perhaps even the platform libs).
Building containers-0.2.0.1...
Data/IntMap.hs:182:7: Could not find module `Data.Data': it is a member of package base, which is hidden
This is because the containers packages doesn't say that it needs base version 4. In fact it doesn't say what version it needs at all.
Duncan