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@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.