Locating shared libraries

[Peter Tanski]

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?

If a binary darcs package requires GHC libraries to function it would  
be a GHC "application," so it would not pass the test.  John  
Skaller's point is actually very good, though it would require  
special changes to the current system: distinguishing between GHC- 
compiled _shared_libraries_ and the GHC compiler itself.

Under the current system ghc sits in its own subdirectory, typically / 
usr/local/lib, /opt/local/lib, etc., depending on your distribution,  
with only the compiler and "base" libraries.  Relatively few Cabal  
packages install into this directory--HaXml does, if i remember  
correctly.  Most Cabal packagers leave the default install, so  
applications compiled by GHC are installed as subdirectories in the  
user library directory (/usr/local/lib).  So we have this layout:

/usr/local/lib/ghc-6.6.1 <--compiler, ghc-distribution libraries
/usr/local/lib/ghc-6.6.1/imports <-- .hi files
after installing HaXml:
/usr/local/lib/ghc-6.6.1 <- HaXml libraries
/usr/local/lib/ghc-6.6.1/imports <-- HaXml .hi files

after installing a default Cabal distribution (here, HXT):
/usr/local/lib/hxt-$(version) <-- libraries
/usr/local/lib/hxt-$(version)/imports <-- hxt .hi files

With the current setup is it is a real pain to go through and  
uninstall all those extra libraries when you upgrade GHC: you must  
either delete the directories completely (for directories based on  
version, such as hxt-$(version), above); or, you must go into each  
directory and delete the old libraries contained there.  The ghc-pkg  
program only handles finding these libraries for the ghc compile  
process; it does not help with uninstalling them except by tracking  
location.

I would extend John's idea--and reference to gcc's install layout:  
everything should go into the generic "ghc" directory, say, /usr/ 
local/lib/ghc; _under_ that should go the compiler version (including  
arch-platform); _under_ that may go user-libraries.  That structure  
would make it much easier for users to uninstall or upgrade ghc  
versions.  It also gives distributors the flexibility to include a  
ghc-library-only distribution (no compiler) for packaging  
applications--say, a basic darcs install (with shared libraries)  
includes only the shared libraries it needs.  A basic "ghc" directory  
on top--no version until the next subdirectory--also preserves prime  
real estate toward the top levels of the directory structure: a user  
may install more than one version of GHC into their home directory  
without flooding their home directory with ghc-$(version)s.

There is a fundamental flaw with all these "new" languages: ABI  
changes between compiler versions force software vendors to give  
customers upgrades of the entire program--you can't send a patch if  
you need to compile all the libraries again.  Static libraries are  
horrible for the same problem, and one of the main reasons I will not  
use OCaml for any distributable application.  Even in-house, a hassle  
like that means time and lost productivity.  Patches are inevitable  
for new features, security, etc., and changes to the compiler are  
inevitable just to get around bugs in the compiler!  GHC is a  
research effort so it is a relatively fast moving target--how much  
Haskell code has bit rotted simply due to changes in the GHC  
compiler? In the past _three_ years?  How much simply due to changes  
in the _interface_ file (.hi) format?  A lot.  Too much to mention here.

Even if we can't standardise the ABI a bit the solution of where to  
put libraries should place some real consideration on how much time  
and trouble it is to uninstall and recompile everything, without  
resorting to a script or package system to do it for us--you may  
imagine the bug bath from, say, modifying ghc-pkg to handle  
uninstallation.

Cheers,
Pete