[Haskell-beginners] Q 2 of 2: GUI and turnkey compiler?

[Rustom Mody]

On Sat, Jun 1, 2013 at 8:14 AM, Brandon Allbery <allbery.b at gmail.com> wrote:

> On Fri, May 31, 2013 at 10:20 PM, Gan Uesli Starling <gan at starling.us>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.)
>
> Note that the gmp case is also not significantly different from any random
> Linux program, and you could in fact choose to bundle the appropriate
> libgmp.so.whatever with your program and use a wrapper script which sets
> LD_LIBRARY_PATH (on Linux or Solaris; DYLD_FALLBACK_LIBRARY_PATH on recent
> OS X).
>
> Part of whats throwing you off, I suspect, is that GHC is a native code
> compiler. You might want to look at what it takes for applications for
> other native compilers, such as C and C++, to bundle necessary libraries.
> Perl is an interpreter, and bundling just means including the necessary
> modules in a local library and making use of local::lib, or at worst 'use
> lib'. It's a much simpler situation than native code compilation. Even in
> the case where a .exe is generated for Windows, it's still making use of
> interpreted code; Perl cannot be compiled to native code at all sanely. The
> .exe instead is instead either a bit like a self-unpacking archive, or a
> wrapper which invokes a Perl interpreter on a module tree with various
> environment variables and paths set. JForth, similarly, is based on the JVM
> instead of native code, and it's trivial to bundle up everything needed in
> a jar.
>
> (Apple's done a fair amount of work to make bundling native code easier by
> means of special linker paths in application and framework bundles which
> both the compile-time ld and the runtime dyld can interpret, but this is of
> course not of any use on Windows or Linux.)
>
>
I believe the problem is deeper than just moving executables from here to
there.

Recently after my debian upgrade, cabal broke.
http://groups.google.com/group/haskell-cafe/browse_thread/thread/72ed1e1eca117fef#

Note: I am not saying that something earlier built with cabal broke with
the upgrade.
cabal itself broke and the message implied something to do with libgmp.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130601/38d62d62/attachment.htm>