Locating shared libraries
p.tanski at gmail.com
Mon Jun 18 11:56:57 EDT 2007
> On Fri, 2007-06-15 at 19:40 -0500, Spencer Janssen wrote:
>> On Sat, 16 Jun 2007 08:21:50 +1000
>> skaller <skaller at users.sourceforge.net> wrote:
>>> One way to measure this is: if you removed GHC and applications,
>>> and there are (necessarily) no users of the remaining library
>>> package .. the library package shouldn't be in the global public
>>> place (/usr/lib+include etc).
>> As I understand it, the entire point of this effort (shared libraries
>> in GHC) is to allow dynamically linked Haskell executables. In this
>> case, applications outside the GHC toolchain will in fact depend on
>> these shared objects. As a concrete case, a binary darcs package
>> be a user of libghc66-base.so and libghc66-mtl.so -- with no
>> dependencies on the GHC compiler package itself.
>> Does this pass your litmus test?
> Yes, it passes the separability test. My darcs wouldn't run otherwise!
> And versioning the library filename as above is a good idea too.
> Felix adds _dynamic for shared libs and _static for static link
> archives to ensure the Linux linker doesn't get confused.
> However, the libs still aren't fully public if the interfaces
> are only private details of the GHC tool chain. Hmmm.
Under the current system, darcs is linked statically so it is a self-
contained executable. Under the proposed shared-library system
versioning the shared libraries may pose a very big problem and I
don't think it would pass your litmus test. As I mentioned
previously, GHC is a fast-moving target and there are quite a few GHC-
Haskell-based applications available that rely on different versions
of the compiler. Here is an example:
There are any number of GHC-Haskell-based programs, all built with
different versions of GHC; GHC itself relies on some of these to
build, such as Happy and Alex. (There are .rpm packages for Alex.)
You already talked about the situation from there: several different
programs relying on different versions of the shared libraries,
located in /usr/local/lib--and they don't rely on just one library.
As is, the GHC runtime system has more than a few base libraries, the
minimum set of which is:
With dynamically linked libraries on OS X, the convention was to have
add the suffix _dyn, so we had:
HSrts_dyn, HSbase_dyn and HSbase_cbits_dyn
Now each GHC-Haskell-based program installer would search /usr/local/
lib for, say, libHSrts_dyn-6.6.1.dylib and install that version if
necessary. What happens on uninstall? The same thing you get on
Windows when you have another program using a particular .DLL--the
uninstall of that version of the library would fail but for unix
systems _only_ if you also have another program using at while you
are doing the uninstall. So if you did not break everything on each
install, eventually you have a complete mess of different versions of
GHC libraries in /usr/local/lib that may have no current use but at
one time were used for several GHC-Haskell-based programs that have
now been upgraded to use something different. Hopefully those who
distributed the binary programs adopted a convention of using the
full version of the library instead of symlinking libHSrts_dyn-6.6.1
to libHSrts_dyn, or as a user several of your older programs might
break after a later one installed a new version of the library and
symlinked that the new version...
That is why I think your idea was good: put everything into distinct
More information about the Glasgow-haskell-users