On Sat, Jun 1, 2013 at 8:43 AM, Rustom Mody wrote:

On Sat, Jun 1, 2013 at 8:14 AM, Brandon Allbery wrote:

...

On Fri, May 31, 2013 at 10:20 PM, Gan Uesli Starling wrote:

...

So, it would be something to allow an author to issue programs which end-users would NOT have to know anything about Haskell itself and would have to, at most, perform a two-step, wholly automatic installation procedure. Short of this, anything I might aspire to give away free to the public en masse, could not conceivably be written in Haskell. In which case, I'll respectfully bow out from endeavoring to learn it myself, however useful it serves for many another purpose.

Aside from system libraries, if you don't configure your packages to be dynamic GHC works that way. You can also force system libraries if you use -static; but note that this also links libc static, which is problematic on at least Linux and Solaris. (Usually, the only problematic system library is gmp.)

I believe the problem is deeper than just moving executables from here to there.

No, there is nothing "deep" about this, and there's nothing specific to Haskell either... As Brandon explained, the notion of a "turn-key compiler" itself isn't adapted here, not because it is Haskell but because ghc is a real compiler : it takes Haskell programs an compile them to native code, that is an executable that can be run directly on the OS/architecture you've compiled for. What I'm going to explain isn't Haskell specific at all but rather general to all compiled languages (C, C++, Go, Pascal, Ada, ...) : So in the beginning the compiler took your code, your libraries and all that and made an self-sufficient executable that contained the native code that could run on your machine and all was good in the world. But the problem is that you put in all this content from your libraries, some of them all your programs are using, and that's a waste, you've got the same native code replicated dozens, hundreds of time all throughout your executables... So we invented shared libraries (.dll on Windows, .so on Linux/Unix) that are already compiled and contains the native code from a library and now when compiling (and linking) an executable, we don't include the library code, we just put in a reference to the shared library and thus our executable are smaller ! So we're better off now, no ? Well.... What if you download an executable and you don't have all the shared libraries it needs (or the wrong versions) ? Suddenly your executable is not self-sufficient anymore ! In Linux, we resolved the problem by using package manager that know what libraries need to be installed for each package to work but it means that if you're not using your manager to install a soft, you'll have to install manually the libraries you need (which is probably what happened to Rustom, its debian upgrade removed or upgraded the libgmp.so his manually installed cabal needed). In Windows we resolved the problem by... nah, let's just pretend we don't care and let the application developers on their own ! Which is the source of dll hell and the reason for which every single application comes with all the dll that are not explicitly provided by windows itself, so that you have a ton of identical versions of the same library in your filesystem. Now in practice, you could still compile all static (no shared libraries, all necessary library code is included in the executable) with the right options to GHC, or you could just compile normally and include the shared libraries in the zip you distribute (on Windows, on Linux it would be better to use the package managers facilities). -- Jedaï

On Sat, Jun 1, 2013 at 12:21 PM, Rustom Mody wrote:

As far as I can see on my machine - cabal is /usr/bin/cabal - the apt package cabal-install is installed and lists /usr/bin/cabal as a file

So unless something really weird or magic-y happened, my cabal is debian's cabal.

And so -- my diagnosis -- the fact that cabal broke after an OS upgrade suggests that the apt package cabal has something wrong in its dependencies.

That sounds reasonable, but also means that your issue is not with Haskell but with Debian. In particular, it is Debian which does things like shifting from ghc's own private libgmp to its system one, thus introducing the possibility that a missed dependency can break things this way. (That said, make certain that you don't have a ~/.cabal/bin/cabal running around first --- if you mix distribution and cabal-install packages, you can easily get into this kind of mess. Which is why we recommend going with one or the other, and in particular not upgrading/replacing anything installed via the distribution except via the distribution.) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net