GHC runtime DLLs

[Peter Tanski]

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:

> p.tanski at gmail.com 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