ghci dynamic loading on MacOSX assumes .dylib extension (should check .so also)
I am using ghc-7.6.3 on MacOSX 10.9.1. I noticed that when -l foo option is specified to ghci, it assumes the shared library extension is .dylib and tries to load foo.dylib. Even though a valid foo.so is present while foo.dylib is not, ghci ignores the .so and signals an error. This is in contradiction to the behavior of gcc and python on MacOSX. gcc would check the existence of both .so and .dylib and try to link them. Python is able to load the .so as well. Notice that here the .so is simply a renamed Mach-O .dylib.
The reason I raise this issue is, in my case, I use macports to install cern ROOT and its shared libraries are all installed as .so files under /opt/local/lib. I would like to use them without change or creating .dylib -> .so links.
$ ghci -lGui GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (dynamic) Gui ... failed. <command line>: user specified .o/.so/.DLL could not be loaded (dlopen(libGui.dylib, 9): image not found) Whilst trying to load: (dynamic) Gui Additional directories searched: (none)
$ ln -s libGui.so libGui.dylib $ ghci -lGui GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (dynamic) Gui ... done final link ... done Prelude>
Trac metadata
| Trac field | Value |
|---|---|
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture |