Locating shared libraries

[Peter Tanski]

On Jun 19, 2007, at 4:05 AM, Simon Marlow wrote:
> Peter Tanski wrote:
>> 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?...
>> That is why I think your idea was good: put everything into  
>> distinct directories.
>
> We are not intending to build-in any particular knowledge about  
> where shared libraries are to be installed - that's up to the  
> packager.

Definitely.  It would be non-portable if GHC baked the install  
directory into the shared library install_name (using libtool lingo)  
whenever a programmer (or Cabal) invoked ghc --make.

> With one exception - we have to pick a default for the .tar.bz2  
> binary distributions (and 'make install'), and the only default  
> that makes sense is to install the shared libraries in the standard  
> location, /usr/local/lib. Otherwise the system will not find them,  
> and GHC itself will not run (assuming it is dynamically linked).   
> You don't get good uninstall support, but that's always been the  
> way if you don't use the system package manager.

I advocated putting everything in /usr/local/lib/ghc/ghc-$(version)  
earlier.  The dynamic-library system used for ghc-6.4 on OS X worked  
fine; do you remember any problems when that was put together?   
Stefan O'Rear seemed against flooding /usr/local/lib with ghc- 
libraries--I'll admit my own /usr/local/lib is a bit messy even  
considering I use 'port' for quite a few programs--but also argued  
that the dynamic libraries should not go in the /usr/local/lib/ghc-$ 
(version).  The de-facto standard for systems that have C or C++- 
compliant dynamic libraries seems to be:

shared libraries go in:
/usr/local/lib

static libraries or system-specific libraries go in:
/usr/local/lib/$(system)/$(system_version) or $(build)/$(system_version)

So for nhc98, the static libraries are in /usr/local/lib/nhc98/$ 
(build); for yhc, the .ycr files are in /usr/local/lib/yhc/packages/ 
yhc-base/$(yhc_version); for felix the .flx files (as source code)  
are in /usr/local/lib/felix/$(felix_version)/lib; for ocaml, the .cmx  
and .cmi files go in /usr/local/lib/ocaml; but for chicken-scheme the  
dynamic libraries (only really usable through the chicken interface  
but definitely "pure" C in the end) are in /usr/local/lib.  I should  
not neglect to say the same goes for python, although .  The one  
exception seems to be for gcc's libstdc++, which has a symlink in the  
same directory as the static libraries.  Following what I--perhaps  
mistakenly--called the 'de facto' standard, if ghc dynamic libraries  
are callable from C (they are), then the dynamic libraries should go  
into /usr/local/lib.  I would highly suggest that symlinking an un- 
versioned name to each version would create a mess, so the library  
names should only follow the real version.  Stefan does have a point,  
so the default installer might place dynamic libraries in a user  
library directory such as $(home)/lib--a real consideration for  
students and others who work on a large shared system where the  
sysadmin does not want to support yet another language installation.

What seems backwards (to me) are the Haskell programs: it would be  
fine if the standard install for program static libraries and  
interfaces went into the ghc-$(version) directory but they don't and  
when we had dynamic libraries on OS X they followed the static  
library convention: each program is installed into /usr/local/lib/$ 
(program) or $(program)-$(version).  Some programs place libraries  
directly into the program directory while others place the libraries  
under a $(haskell_compiler)-$(haskell_compiler_version) directory.   
This duplicates the ghc system of /usr/local/lib/ghc-$(version) for  
each Haskell program and creates a real mess--more so than other  
languages.  I agree, this is not really GHC's problem but the ghc  
location might help, which is why I suggested /usr/local/lib/ghc/ghc-$ 
(version).  It might even be extendable to all of Haskell: ghc should  
go into /usr/local/lib/haskell/ghc-$(version), so, say, yhc could go  
into /usr/local/lib/haskell/yhc and the installed programs would go  
into /usr/local/lib/haskell/$(compiler).  Much cleaner and much  
easier for a package system to manage.

I have written too much on this, so I'll shut up--whatever you decide  
is fine; I'll fix the install script to create a PackageMaker .pkg   
following whatever you decide and post it if you want it.

Cheers,
Pete