GHC runtime DLLs
p.tanski at gmail.com
Sun Jul 30 15:19:22 EDT 2006
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://
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.)
On Jul 30, 2006, at 12:33 PM, Brian Hulley wrote:
> p.tanski at gmail.com wrote:
>> 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
>> 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.
More information about the Glasgow-haskell-users