Opened 9 months ago

Last modified 5 months ago

#8420 new bug

Spurious dynamic library dependencies

Reported by: AndreasVoellmy Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.6.3
Keywords: Cc:
Operating System: MacOS X Architecture: Unknown/Multiple
Type of failure: None/Unknown Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:


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.

Attachments (1)

TestDylib2.tgz (1.4 KB) - added by AndreasVoellmy 9 months ago.
test case

Download all attachments as: .zip

Change History (4)

Changed 9 months ago by AndreasVoellmy

test case

comment:1 Changed 5 months ago by darchon

It doesn't just apply to OS X, also to linux:

[10:19am] <christiaanb>
Does also apply to linux?
[10:30am] <slyfox^w_>
yeah, it does. -Wl,--as-needed partially mitigates it, but RPATH is left

comment:2 Changed 5 months ago by nomeata

I also noticed the problem; we’d like to generate our Debian package dependencies based on what files are linked, but currently that is an over-approximation. I.e. lots of stuff links to libgmp.

I believe Ubuntu and OpenSUSE patch their build to use -Wl,--as-needed, but I refrained from it, to prevent unnecessary divergence. But I would very much welcome if GHC would build with -as-needed, preferably already in GHc-7.8 (as now we build libHS*.so files by default for all packages).

comment:3 Changed 5 months ago by darchon

It would be my guess this has something to do with the fact(?) that the original pipeline was build with static linking in mind? In which case you would need the transitive closure of the libraries you depend on?

Looking at linkBinary' in compiler/main/DriverPipeline.hs, I see that it just gets a list of PackageId's that must be linked, for which, as far as I can see, there is no differentiation between dynamic linking and static linking.

Last edited 5 months ago by darchon (previous) (diff)
Note: See TracTickets for help on using tickets.