Spurious dynamic library dependencies

It should be possible to have an executable A that depends on dynamic library B which in turn depends on dynamic library C, without A directly depending on C. A --> B --> C Unfortunately, GHC 7.6.3 does not seem to allow this. Instead it copies the dependencies of B to dependencies of A, so that we get A -> B,C and B --> C

This is unfortunately, because running A will cause the loader to locate C based on the rpaths (assuming we are using rpaths to locate dynamic libraries), whereas only B should know how to get to C from B.

The problem seems to be that ghc copies all the library dependencies of B (presumably from the package specification of B) as library dependencies of the A.

I verified the problem in GHC 7.6.3, but haven't tried in HEAD yet.

Trac metadata

Trac field	Value
Version	7.6.3
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system	MacOS X
Architecture

B --> C }}}\r\nUnfortunately, GHC 7.6.3 does not seem to allow this. Instead it copies the dependencies of B to dependencies of A, so that we get\r\n{{{ A -> B,C and B --> C }}}\r\n\r\nThis is unfortunately, because running A will cause the loader to locate C based on the rpaths (assuming we are using rpaths to locate dynamic libraries), whereas only B should know how to get to C from B.\r\n\r\nThe problem seems to be that ghc copies all the library dependencies of B (presumably from the package specification of B) as library dependencies of the A. \r\n\r\nI verified the problem in GHC 7.6.3, but haven't tried in HEAD yet.","type_of_failure":"OtherFailure","blocking":[]} -->