I've put up a new InstallShield for GHC 4.08.1 (Windows edition). This no longer contains DLLs and import libraries for the libraries, so you have to use the compiler with -static.
Hmm ... That's really a fundamental change in GHC's Windows edition.
I intend to stick to this scheme in future releases (probably replacing -static with -dynamic
Good idea! :-) I also regard statically linking as more common than dynamically linking, so I welcome your idea to make statically linking the default.
), as GHC derives few benefits from DLLized libraries, and a lot of disadvantages. 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.) 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.
Users of DLLs need not despair: one important (and, to the best of my knowledge, fully working) version of DLL building remains: you can still build static DLLs, that is, DLLs in which all the code has been compiled statically, so that all the necessary library code is linked into the DLL. Hence, you can still build DLLs to be called from other languages, or to be wrapped up as COM components, or whatever.
Exposing Haskell functions to other languages in DLLs is a very, very important feature of GHC's Win edition! Please go on supporting it as you do!!
Finally, one nice side effect is that the size of the distribution is nearly halved: it now weighs in at a little over 12Mb.
Cheers, Christian
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.
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). -- http://sc3d.org/rrt/ | computation, n. automated pedantry
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
Hi Reuben,
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?
There are some strange things happening that I'm still astonished about. I decided just to write them down again - perhaps it may help to discover the error of the linking problem. As you know, I made some trials with a statically linked DLL build with GHC4.08.1 and the latest cygwin. a) When leaving debug information as it is, everything works fine - in all environments I tested it on (WinNT, Win95; VBA, Delphi, VB - I had no possibility to test it on Win2K yet). b) When STRIP-ping away the debug information, the DLL on all PCs I tried it on works fine with VB and Delphi - but when using it in VBA, it on some PCs crashes when the DLL is loaded (the loading happens automatically when calling a Haskell function for the first time) - this also looks like a problem during DLL initialization, it seems as if DllMain is not even entered. Did you already try out a statically linked, stripped DLL on Win2K? Do you get the same error? (If the origin of the error is the same DLL initialization problem as in the linking problem with EXEs, it may be easier to handle in a hell of a single DLL ...) Some more strange things occured with the small program we had with catchAllIO / the "hi" output: I compiled it in both ways with and without the "-static" option and sent the EXE binaries to Arjan van Ijzendoorn (who reported the error). a) When running the EXEs on my PC (Win95), both the statically and the dynamically linked EXE work well (output: "hi"). b) The same EXE on A.v.I.'s PC with Win2K produced the "famous" application error. Do you have some idea what's wrong here? Cheers, Christian
participants (2)
-
Christian Lescher -
Reuben Thomas