#12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Comment (by simonmar): * db1: p (depends on q) * db2: q (depends on r from db3) * db3: r * db4: r (shadows r from db3) I presume you mean that db3:r and db4:r have different ABIs, and q was built against db3:r. We are given these in the order db1, db3, db4, db2. Now, since q's dependency doesn't say which r it requires, we have to pick one, and the only sensible strategy is to pick the rightmost (db4:r). This is the wrong r, so we can get segfaults. Given that we can get segfaults even trying to do clever shadowing, I'm going to suggest that we don't do clever shadowing at all. * Just merge databases from left to right. When there are multiple packages with the same key, we get the rightmost one. We would accept the small possibility that if someone has somehow managed to create two packages with the same key but different ABIs (which is difficult with determinism) then GHC can produce a segfaulting binary. Too bad. It's unlikely, and as a user you can fix it by deleting or rebuilding packages. Furthermore it was always possible to screw up like this because the ABI hash is not a complete specification of a package - there are semantic differences not captured by the ABI hash. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12485#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler