On Jun 18, 2007, at 6:06 PM, Stefan O'Rear wrote:

On Mon, Jun 18, 2007 at 11:56:57AM -0400, 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.

Debian's high level package manager will automatically garbage collect dependancies, such that every package on your system is either manually selected for install or a dependant of one. Thus there is no library leak problem.

The Debian package system (I assume you are referring to apt, or maybe dpkg?) is very convenient (and relatively quick!). I don't know how well the BSD-style package systems garbage collect but I have not had any problems using port or fink--though sometimes they pull more dependancies than they need because installed programs outside their system are (wisely) not considered. Since my best machine is a Mac (PowerBook G4, 1.25GHz) the lost libraries become a problem as soon as I work independently of a package system. I expect the same would be true for anyone working independently. Some individual languages have their own package systems, such as Lisp's asdf; OCaml has GODI. Haskell is moving in that direction with Cabal but it is still more of a build system than anything else and in any case it would probably be better to keep with the system packaging setup, such as Debian's, for program distribution. That way GHC libraries may reside comfortably in the standard system directories but I am still a little querulous. I would rather all haskell libraries use the standard (OS X) DYLD_LIBRARY_PATH, though DYLD_FALLBACK_LIBRARY_PATH (putting things in $(home)/lib) might help for the haskell-universe. That may be the solution for programs, though it requires more work: Haskell would need packaging. On a related note, if anyone is interested, once we get an idea of where we want to put things I can modify the installer script to create an OS X pkg (using PackageMaker) for GHC binary distributions. At least that would make removal easier (using Desinstaller). The old 6.4.1 OS X application install was slick; I might redo that. Cheers, Pete

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