ghci does not consider library-dirs of dependent packages for dlopen()
On OSX, when ghci loads a package (eg ghci -package gtk) it uses dlopen on the .dynlib files specified in the package registration. However it appears to look only in the library-dirs of the package itself and not of the dependent packages.
This shows up with gtk2hs on OSX when the glib and gtk C libs are in a non-standard location (/opt/local/lib). The glib package registration file uses library-dirs: /opt/local/lib and the gtk package depend on the glib package. The gtk package requires the C lib libgthread-2.0.dynlib. This exists in /opt/local/lib however when loading the gtk package in ghci, it does not look in /opt/local/lib. It only does so if we modify the gtk registration file to specify library-dirs: /opt/local/lib.
This behaviour of not using the lib dirs of dependent packages is inconsistent with the static linking case. I suspect this bad behaviour is specific to OSX, because I think this has always worked in the gtk2hs windows installers.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |