Brian,
Sorry, I smash out emails without thinking and forgot GHC is
distributed with static archives in Windows. No more. Even if you
build the GHC runtime library from source as DLLs you will run into
another problem, as noted in the DLL-NOTES file (see http://
cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/DLL-NOTES?
rev=1.1;content-type=text%2Fplain or the file compiler/DLL-NOTES in
the distribution): some of the runtime system must be statically
linked into your main executable in order to resolve all the symbols
at compile-time. The only way around this is to treat those runtime
libraries like plugins. A good reference is http://
edll.m2osw.com/ . I have honestly not used EDLL on GHC runtime
libraries, but it should be possible.
One of the main goals for the next major release of GHC is to make it
Windows-native and use Microsoft's CL. I think that is another big
project The disadvantage to "free" software is that it often
feels like you are trying to build a car with spare parts; either you
spend your time porting and fixing things yourself--an almost daily
task, these days--or you wait for someone with more experience or
time than you have to fix it for you (which may never happen, or may
not happen the way you want it). The advantage to free software is
that, like the Haskell language, you get to use some of the most
advanced programming available. So here I am, trying to figure out
what I can do to help GHC, since right now GHC is the only actively
maintained, current Haskell compiler available. (In any case, nhc98
uses GMP as well, so even if you use nhc98 you will still have the
DLL-NOTES problem to deal with.)
Best Regards,
Peter
On Jul 30, 2006, at 12:33 PM, Brian Hulley wrote:
[EMAIL PROTECTED] wrote:
Brian,
The standard method of skirting the LGPL restriction and saving your
source code is to link dynamically in a separate step and then
distribute your program along with the dynamically linked LGPL'd
library. Compile with ghc -c (or with ghc -c -odir 'separate
directory where you want to store the object files') and pass
specific
lines to the linker through gcc with -optc. Then link the object
files for your program separately using ld and distribute the ghc
runtime libraries you need to dynamically link along with your
program. Some of these runtime libraries are big but on average
libHSrts_dyn, libHSbase_dyn and libHSbase_cbits_dyn do the trick (I
have needed cbits up for programs that use -ffi).
Hi -
I think the main problem here is that I'm using Windows, so there
is no way to dynamically link with the runtime libraries - the GHC
implementations available for Windows only produce statically
linked executables.
Perhaps Windows support was just an afterthought from the main
development of GHC on Unix, but I think it's quite a serious
nusiance that the GHC runtime incorporates LGPL'd components in the
light of the absence of the facility to dynamically link with it on
this platform.
Regards, Brian.
--
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.
http://www.metamilk.com
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
