ghci dynamic loading on MacOSX assumes .dylib extension (should check .so also)
|Reported by:||z9p||Owned by:|
|Keywords:||dlopen dylib so||Cc:||hvr|
|Operating System:||MacOS X||Architecture:||x86_64 (amd64)|
|Type of failure:||None/Unknown||Test Case:|
|Related Tickets:||Differential Rev(s):|
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>
Change History (4)
comment:1 Changed 3 years ago by thoughtpolice
- Milestone set to 7.8.1
- Version changed from 7.6.3 to 7.8.1-rc1