skaller wrote:
On Fri, 2007-06-15 at 19:40 -0500, Spencer Janssen wrote:
On Sat, 16 Jun 2007 08:21:50 +1000
skaller <[EMAIL PROTECTED]> 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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
