Pete Chown <[email protected]> writes: > Ivan Miljenovic wrote: > >> Pete Chown <[email protected]> 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 [email protected] IvanMiljenovic.wordpress.com _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
