[Haskell-cafe] Re: Problems with Haskell Platform

Ivan Lazar Miljenovic ivan.miljenovic at gmail.com
Wed Jun 2 07:37:24 EDT 2010

Pete Chown <1 at 234.cx> writes:

> Ivan Miljenovic wrote:
>> Pete Chown <1 at 234.cx> wrote:
>>> ... This causes Cabal to install 'foo' (because it
>>> is a dependency) and it won't use the distribution's package manager.
>> Why won't it?  This, of course, depends on how the distribution ships
>> `foo' in regards to static/shared libraries and what the user's
>> options to Cabal/cabal-install are.
> Is there a way of making Cabal install dependencies using the system
> package manager, then?
> For example, I might ask Cabal to install package A.  Package A
> depends on B and C.  A package for B can be downloaded through APT,
> but there are no APT-installable candidates for A and C.  Are you
> saying that Cabal can download and install B using APT, then download
> A and C from Hackage?

If you mean cabal-install, then no, there's no integration on either

>> In general, even if some application is built statically then it won't
>> work on other machines due to different C library versions (GMP,
>> etc.), so I don't think this is such a big deal.
> Your program should run on other machines that use the same Linux
> distribution, though.  The problem is that this won't happen if Cabal
> ends up building its own shared libraries.  For simplicity, let's have
> a new example...  The user asks Cabal to install package X, so Cabal
> goes to Hackage and gets the latest version,  It builds
> shared libraries from it.  Meanwhile, the distribution actually
> packaged X version  The user's programs could have been
> linked against, and then they would have run on all systems
> using that distribution.  As it is, the programs only work on the
> user's own machine, because that's the only machine with the
> shared library.

This is exactly the same with C programs.

> One option is to stop Cabal building shared libraries.  That would
> avoid the worst of these problems, but it would still be sub-optimal.
> The user might want to link against shared libraries, but he won't
> have the chance, because he installed X from the wrong place.
> (I believe current versions of ghc insist on linking entirely
> dynamically or entirely statically.  This makes the situation worse,
> because the lack of a shared library for X prevents the use of shared
> libraries for anything else.)

No, 6.12 defaults to statically but allows dynamic linking as well.

>> Of course, the big thing here is whether Linux distributions, etc.
>> should ship static or shared libraries by default.
> With other languages they tend to ship both, and give the user the
> choice, I suppose.

Really?  For C, Gentoo ships very few which either default or have the
option of static libraries, and I assume the same is true for binary

Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com

More information about the Haskell-Cafe mailing list