Opened 4 years ago

Closed 21 months ago

#8947 closed bug (invalid)

Depending on hint/ghc API fixes the binary version I can use

Reported by: nh2 Owned by:
Priority: normal Milestone:
Component: GHC API Version: 7.6.3
Keywords: Cc: mail@…, mail@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: GHC rejects valid program Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


When I build-depend on hint- with GHC 7.6.3, I get

% cabal configure
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: pointcloudviewer-0.1.0 (user goal)
trying: hint- (dependency of pointcloudviewer-0.1.0)
trying: ghc-7.6.3/installed-494... (dependency of
trying: bin-package-db- (dependency of
trying: GLUtil-0.7.4/installed-223... (dependency of pointcloudviewer-0.1.0)
next goal: linear (dependency of GLUtil-0.7.4/installed-223...)
rejecting: linear-1.6/installed-300... (conflict: bin-package-db =>
binary==, linear => binary==

This fails because linear uses a binary >, but through my use of hint which depends on ghc (hint does not directly depend on binary), I pull in a constraint binary ==

I believe this is bad, because depending on the GHC API in any way fixes the binary version I can use, which immediately makes a range of newer libraries unavailable to my program.

Probably GHC should somehow hide the fact that binary is used inside, and let the rest of my program use whatever binary it likes.

I am aware that this might not be immediately easy, since the GHC API might expose some binary types to my program that I could try use with my newer binary version, which of course would be illegal.

Maybe it is possible to implement such a check into actual typechecking, and let it pass if I don't actually use types from the old version with functions from the new library. I actually believe I have seen compiler errors in the past where two identical types where not unified because one was from a different version, so maybe infrastructure for this is already in place?

Change History (5)

comment:1 Changed 4 years ago by nomeata

Cc: mail@… added

comment:2 Changed 3 years ago by thomie

Keywords: backpack added

comment:3 Changed 2 years ago by ezyang

Technically this is this Cabal bug: the required feature is for Cabal to understand how some dependencies of a package should be considered "private" and thus have an extra degree of freedom when dependency solving. GHC already has the capability to link against multiple versions of binary; the problem is convincing Cabal that this is kosher.

comment:4 Changed 2 years ago by ezyang

Keywords: backpack removed

comment:5 in reply to:  3 Changed 21 months ago by thomie

Resolution: invalid
Status: newclosed

Replying to ezyang:

Cabal bug:

Note: See TracTickets for help on using tickets.