Also, there is at present an unresolved and deep-seated bug (possibly not even in GHC) that prevents some very simple DLLized programs from working.
When may Win users expect this bug to be fixed? (A difficult question, I know.)
I've given up on it for the moment; having looked at the source code of ld, asked on the binutils and Cygwin mailing lists, and a few other things, I can't work out what the problem is. I do have a few more things to try, but I don't hold out much hope of fixing it soon without help.
I'd like to offer help, but I'm afraid I don't know enough about the 'interna' of GHC and cygwin :-( [Would be nice, if I could learn more about it in the future!] Besides, I've got some (not so fortunate) news: even after updating binutils and the whole cygwin to the latest version, the problem with *statically* linked and afterwards stripped DLLs build with GHC remains - the unstripped version works well, but the stripped one crashes in some constellations. I will try to make this error reproducable and let you know about it. Something is still wrong here - probably with cygwin. Maybe this has also got something to do with the dyn. linking problem?
Although I regard statically linking as much more important than the DLLized alternative, dynamically linking is (was?) an important feature of GHC for Win - f.e. to safe space when distributing a bunch of EXEs / DLLs build with GHC.
This is only a good idea if you really are distributing several DLLs or EXEs built with GHC (so that you do get space savings), and even then you have to ask yourself if it's worth the risk of DLL Hell (which I have suffered from several times). Disk space is so cheap now that you really have to be hurt somewhere (e.g. increased download times, decreased performance because of large unshared binaries) before it's worth dynamic linking (except to relatively stable system libraries).
Yes, that's true. However, dynamically linking would be a feature. Cheers, Christian