[Haskell-cafe] Re: Problems with Haskell Platform

[Ivan Lazar Miljenovic]

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
side.

>> 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, 1.2.3.5.  It builds
> shared libraries from it.  Meanwhile, the distribution actually
> packaged X version 1.2.3.4.  The user's programs could have been
> linked against 1.2.3.4, 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 1.2.3.5
> 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
distributions.

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
IvanMiljenovic.wordpress.com