Locating shared libraries

[Peter Tanski]

skaller wrote:
> 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  
>> could
>> 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:

HSrts
HSbase
HSbase_cbits

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  
directories.

Cheers,
Pete