Re: New InstallShield: no more DLLs
Christian Lescher <christian <at> lescher.de>
2000-12-07 07:35:12 GMT
> 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
As you know, I made some trials with a statically linked DLL build with GHC4.08.1 and the
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
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"