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