Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
I am still using ghc 6.4.2 for creating my DLL and, as long as the DLL does not open a file, releasing the DLL works fine. I have not yet tried ghc 6.5. Michael SevenThunders wrote: Michael Marte wrote: Hello *, before filing a bug report, I want others to comment on my problem. Maybe it's my fault, not ghc's. I wrapped up some Haskell modules in a Win32 DLL. Loading the DLL dynamically (with LoadLibrary) works fine. However, whether I actually use the library or not, the program (an application with MFC GUI) crashes upon termination. I was wondering if there has been any recent progress on this issue. I have a binary windows distribution of GHC 6.5. from May 02 2006. I created a Haskell DLL that is called from a C stub, which ultimately gets called from Matlab. I'm not sure if Matlab loads and unloads the DLL everytime it's called, but it definately crashes Matlab if one tries to unload the DLL from inside Matlab (using Matlab's clear command). The crash occurs even if no Haskell code is actually called from Matlab. It suffices to simply load the Haskell DLL and then unload it. If you do call the DLL it will work for the first few times and then eventually crash. Presumably there is some kind of memory leak as alluded to elsewhere in this thread. I'm looking for usable workarounds here. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Michael Marte wrote:
I am still using ghc 6.4.2 for creating my DLL and, as long as the DLL
does not open a file, releasing the DLL works fine. I have not yet tried
ghc 6.5.
Michael
I just tried it under GHC 6.6 with the same results. If the DLL is loaded it
crashes when it's unloaded even if no Haskell code is actually executed.
Again I am calling this from Matlab 6.5 so I have no idea how Matlab is
handling the loading and unloading of the DLL or what it is doing to the
environment. All that is clear is that if the code needs to be linked to
the Haskell DLL, the phenomenon occurs.
My DLL main program was lifted from the documentation and looks like this.
#include windows.h
#include Rts.h
extern void __stginit_ExternLib(void);
static char* args[] = { ghcDll, NULL };
/* N.B. argv arrays must end with NULL */
BOOL
STDCALL
DllMain
( HANDLE hModule
, DWORD reason
, void* reserved
)
{
if (reason == DLL_PROCESS_ATTACH) {
/* By now, the RTS DLL should have been hoisted in, but we need to
start it up. */
startupHaskell(1, args, __stginit_ExternLib);
return TRUE;
}
return TRUE;
}
ExternLib.hs is the external Haskell program that I link to but I don't
actually call. I could probably generate a simple example of the problem,
which perhaps I shall do and post shortly.
--
View this message in context:
http://www.nabble.com/GHC-6.4.1-and-Win32-DLLs%3A-Bug-in-shutdownHaskell--tf1206938.html#a6978317
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabble.com.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
SevenThunders wrote:
I just tried it under GHC 6.6 with the same results. If the DLL is loaded
it crashes when it's unloaded even if no Haskell code is actually
executed.
Here is the promised simple example. This example will cause an exception
when the DLL is unloaded, but it doesn't seem to cause the run time
exception that a more complicated example might cause. This could be
because of the very small amount of memory it actually uses.
dllNet.c -
#include windows.h
#include Rts.h
extern void __stginit_ExternLib(void);
static char* args[] = { ghcDll, NULL };
/* N.B. argv arrays must end with NULL */
BOOL
STDCALL
DllMain
( HANDLE hModule
, DWORD reason
, void* reserved
)
{
if (reason == DLL_PROCESS_ATTACH) {
/* By now, the RTS DLL should have been hoisted in, but we need to
start it up. */
startupHaskell(1, args, __stginit_ExternLib);
return TRUE;
}
return TRUE;
}
ExternLib.hs -
module ExternLib where
foreign export stdcall hinc :: Double - Double
hinc :: Double - Double
hinc dval = dval + 1.0
- matlabinterf.c -
#include stdlib.h
#include string.h
#include assert.h
#include stdio.h
#include mex.h
#ifndef FFI_H
#define FFI_H
typedef unsigned int HsChar; // on 32 bit machine
typedef int HsInt;
typedef unsigned int HsWord;
typedef void *HsPtr;
typedef void (*HsFunPtr)(void);
typedef void *HsForeignPtr;
typedef void *HsStablePtr;
typedef double HsDouble ;
#define HS_BOOL_FALSE 0
#define HS_BOOL_TRUE 1
#endif // FFI_H
__declspec(dllimport) HsDouble __stdcall hinc(HsDouble ival) ;
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
HsDouble *ival, *oval ;
mxArray *mret ;
/* We check the number of input and output arguments*/
if (nrhs != 1)
mexErrMsgTxt(Error: this needs 1 input argument) ;
ival = mxGetPr(prhs[0]) ;
/* create a 1 x 1 real matrix for the output */
mret = mxCreateDoubleMatrix(1,1, mxREAL) ;
plhs[0] = mret ;
oval = mxGetPr(plhs[0]) ;
*oval = hinc(*ival) ;
}
Here is the batch file I use to create the Haskell DLL. It assumes MS VC
tools are in the
search path.
--- ghcdll.bat --
ghc -O2 -c ExternLib.hs -fglasgow-exts
ghc -c dllNet.c
ghc --mk-dll -fglasgow-exts -o interf.dll ExternLib.o ExternLib_stub.o
dllNet.o -L. -optdll--def -optdllinterf.def
lib /def:interf.def /MACHINE:X86
-- interf.def
LIBRARYinterf.dll
EXPORTS
[EMAIL PROTECTED]
hinc = [EMAIL PROTECTED]
Run the following commands in Matlab to load and unload the Haskell DLL
mex matlabinterf.c interf.lib
y = matlabinterf(0)
clear matlabinterf
Matlab will crash with an unhandled exception after calling a floating point
division operation. It is possible to actually make it so that the haskell
code is not called at all but merely linked and thus loaded when the dll is
loaded. The crash still occurs. I suspect Matlab must be accessing some
kind of resource used by the DLL that is not shut down properly when the DLL
is unloaded. However in more complicated examples Matlab will eventually
crash after multiple calls to perfectly good Haskell code, whether or not
the DLL is unloaded. Next I will try to see if I can duplicate this outside
of a Matlab environment.
--
View this message in context:
http://www.nabble.com/GHC-6.4.1-and-Win32-DLLs%3A-Bug-in-shutdownHaskell--tf1206938.html#a6980729
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabble.com.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
On Tue, 2006-10-24 at 13:16 -0700, SevenThunders wrote: Here is the promised simple example. This example will cause an exception when the DLL is unloaded, but it doesn't seem to cause the run time exception that a more complicated example might cause. This could be because of the very small amount of memory it actually uses. I know nothing of Matlab or Haskell linkage .. so do you know which C library they're linked against? It has to be the same one, and it must be dynamic linkage. (Felix build was inconsistent and we got similar random behaviour). -- John Skaller skaller at users dot sf dot net Felix, successor to C++: http://felix.sf.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
I'm not sure exactly how to determine which runtime libraries Matlab 6.5 uses. However since I am compiling the mex code via Microsoft VC++ 6.0, I suspect that the Haskell DLL s are loaded using the MS VC 6.0 runtime libraries. The DLL that contains the interface code however is probably loaded using whatever libraries Matlab links to. Ultimately they both should just be calling the operating system load and unload routines. How did you resolve your problems? skaller wrote: On Tue, 2006-10-24 at 13:16 -0700, SevenThunders wrote: Here is the promised simple example. This example will cause an exception when the DLL is unloaded, but it doesn't seem to cause the run time exception that a more complicated example might cause. This could be because of the very small amount of memory it actually uses. I know nothing of Matlab or Haskell linkage .. so do you know which C library they're linked against? It has to be the same one, and it must be dynamic linkage. (Felix build was inconsistent and we got similar random behaviour). ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
On 09 March 2006 18:19, Michael Marte wrote: Simon Marlow wrote: Michael Marte wrote: Lennart Augustsson wrote: I'm not implying anything, except that I've plugged the space leak of 256M every time a DLL is loadedunloaded. -- Lennart Michael Marte wrote: Lennart, do you imply that you have fixed the problem causing the crashes? May I safely assume that DLLs produced by ghc 6.4.2 will not crash upon being freed? I wanted to test the fix for ticket #711 but I am stuck because there is no current snapshot of ghc 6.5 for mingw. (The last one is dated end of February, the patch was commited on March, 2nd.) The patch hasn't been committed at all, AFAIK. Ok, it am new to Darcs, so this patch is only a proposal contained in the ticket? I saw that the patch is scheduled for milestone 6.4.2 but has been commited only for 6.5. When will it be available for 6.4.2? I started learning to compile ghc and I have succeeded with the current head of the 6.4 branch on Debian Linux/testing. Next step is to compile the head on this system. My current problem is a missing symbol when linking stage1/ghc-6.5, namely u_gencat referenced by stage1/parser/Lexer.o. Am I missing some library? (I think my sources are up to date, I pulled only half an hour ago.) When compiling with 6.4.1 or later, u_gencat should come from libHSbase_cbits.a in your 6.4.1 installation. Is it there? No, I am compiling with plain 6.4 (a newer Debain package is not available) and it does not have u_gencat in this library. However I can compile the head of the 6.4 branch which in turn should be able to compile the head, shouldn't it? Yes, I think a plain 6.4 can't compile the HEAD right now. We'll try to fix this, but for now you should use a 6.4.1 or later. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Michael, I've found more bugs. There are several race conditions when a DLL is unloaded. The extra threads that the GHC runtime system starts (at least one is always started to generate timer ticks) are not shut down in a synchronized way. This means that they might be scheduled to run after the DLL has been unloaded. Which gives you an access violation. I don't have a proper fix for this yet. -- Lennart Michael Marte wrote: Lennart, do you imply that you have fixed the problem causing the crashes? May I safely assume that DLLs produced by ghc 6.4.2 will not crash upon being freed? I played around a little bit more and found two configurations that do not crash, at least not when freeing the DLL in the course of quitting the application: - compilation with -O, execution with standard heap size - compilation with -O, execution with -M128m. With 64m initial heap space, the problems described earlier occur again :-( Michael Lennart Augustsson wrote: The memory allocated by the runtime system is never freed. I've submitted a fix fir this. -- Lennart ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Lennart Augustsson wrote: I've found more bugs. There are several race conditions when a DLL is unloaded. The extra threads that the GHC runtime system starts (at least one is always started to generate timer ticks) are not shut down in a synchronized way. This means that they might be scheduled to run after the DLL has been unloaded. Which gives you an access violation. I don't have a proper fix for this yet. Is this with -threaded? Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Michael Marte wrote: Lennart Augustsson wrote: I'm not implying anything, except that I've plugged the space leak of 256M every time a DLL is loadedunloaded. -- Lennart Michael Marte wrote: Lennart, do you imply that you have fixed the problem causing the crashes? May I safely assume that DLLs produced by ghc 6.4.2 will not crash upon being freed? I wanted to test the fix for ticket #711 but I am stuck because there is no current snapshot of ghc 6.5 for mingw. (The last one is dated end of February, the patch was commited on March, 2nd.) The patch hasn't been committed at all, AFAIK. I saw that the patch is scheduled for milestone 6.4.2 but has been commited only for 6.5. When will it be available for 6.4.2? I started learning to compile ghc and I have succeeded with the current head of the 6.4 branch on Debian Linux/testing. Next step is to compile the head on this system. My current problem is a missing symbol when linking stage1/ghc-6.5, namely u_gencat referenced by stage1/parser/Lexer.o. Am I missing some library? (I think my sources are up to date, I pulled only half an hour ago.) When compiling with 6.4.1 or later, u_gencat should come from libHSbase_cbits.a in your 6.4.1 installation. Is it there? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
No, the timer thread starts even without -threaded. If you use -threaded it gets worse because then you have a bunch of other threads that don't exit properly. -- Lennart Quoting Simon Marlow [EMAIL PROTECTED]: Lennart Augustsson wrote: I've found more bugs. There are several race conditions when a DLL is unloaded. The extra threads that the GHC runtime system starts (at least one is always started to generate timer ticks) are not shut down in a synchronized way. This means that they might be scheduled to run after the DLL has been unloaded. Which gives you an access violation. I don't have a proper fix for this yet. Is this with -threaded? Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Simon Marlow wrote: Michael Marte wrote: Lennart Augustsson wrote: I'm not implying anything, except that I've plugged the space leak of 256M every time a DLL is loadedunloaded. -- Lennart Michael Marte wrote: Lennart, do you imply that you have fixed the problem causing the crashes? May I safely assume that DLLs produced by ghc 6.4.2 will not crash upon being freed? I wanted to test the fix for ticket #711 but I am stuck because there is no current snapshot of ghc 6.5 for mingw. (The last one is dated end of February, the patch was commited on March, 2nd.) The patch hasn't been committed at all, AFAIK. Ok, it am new to Darcs, so this patch is only a proposal contained in the ticket? I saw that the patch is scheduled for milestone 6.4.2 but has been commited only for 6.5. When will it be available for 6.4.2? I started learning to compile ghc and I have succeeded with the current head of the 6.4 branch on Debian Linux/testing. Next step is to compile the head on this system. My current problem is a missing symbol when linking stage1/ghc-6.5, namely u_gencat referenced by stage1/parser/Lexer.o. Am I missing some library? (I think my sources are up to date, I pulled only half an hour ago.) When compiling with 6.4.1 or later, u_gencat should come from libHSbase_cbits.a in your 6.4.1 installation. Is it there? No, I am compiling with plain 6.4 (a newer Debain package is not available) and it does not have u_gencat in this library. However I can compile the head of the 6.4 branch which in turn should be able to compile the head, shouldn't it? Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Lennart Augustsson wrote: I'm not implying anything, except that I've plugged the space leak of 256M every time a DLL is loadedunloaded. -- Lennart Michael Marte wrote: Lennart, do you imply that you have fixed the problem causing the crashes? May I safely assume that DLLs produced by ghc 6.4.2 will not crash upon being freed? I wanted to test the fix for ticket #711 but I am stuck because there is no current snapshot of ghc 6.5 for mingw. (The last one is dated end of February, the patch was commited on March, 2nd.) I saw that the patch is scheduled for milestone 6.4.2 but has been commited only for 6.5. When will it be available for 6.4.2? I started learning to compile ghc and I have succeeded with the current head of the 6.4 branch on Debian Linux/testing. Next step is to compile the head on this system. My current problem is a missing symbol when linking stage1/ghc-6.5, namely u_gencat referenced by stage1/parser/Lexer.o. Am I missing some library? (I think my sources are up to date, I pulled only half an hour ago.) Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
I'm not implying anything, except that I've plugged the space leak of 256M every time a DLL is loadedunloaded. -- Lennart Michael Marte wrote: Lennart, do you imply that you have fixed the problem causing the crashes? May I safely assume that DLLs produced by ghc 6.4.2 will not crash upon being freed? I played around a little bit more and found two configurations that do not crash, at least not when freeing the DLL in the course of quitting the application: - compilation with -O, execution with standard heap size - compilation with -O, execution with -M128m. With 64m initial heap space, the problems described earlier occur again :-( Michael Lennart Augustsson wrote: The memory allocated by the runtime system is never freed. I've submitted a fix fir this. -- Lennart ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Cyril, - How to generate an import library at all? Section 11.5.1 of the ghc manual says that the --mk-dll option will cause ghc to create such a library, but ghc 6.4.1 does not do this, at least not on Windows. Or did you use the Microsoft lib.exe? (lib.exe /def Foo.def generates an import library from the DLL but I have no idea how use it. After all, lib.exe does not have any type information on the symbols exported by the DLL, so how is this is supposed to work?) - Assuming I have obtained an import library, how to use in the Microsoft world, i.e. how to bridge the gap from .a to .lib? - Is Visual Studio 7 able to process the header files included from the stub header files generated by ghc? Visual Studio 6 has a lot of problems, e.g. it knows nothing about the type long long. - Didn't you have problems with mangled names? - What is the principal difference between using the import library and writing one on my own? Does the import library do anything else than loading the library and delegating the calls? It would be great if you could give me a recipe (in terms of a shell-command sequence) that demonstrates how you achieved your goal! Michael BTW. If I learn anything from this thread that is not yet contained in the Haskell Wiki page pointed to by Simon, I will add it. Cyril Schmidt wrote: Did you try to link the DLL statically (i.e. via import library) and remove the call to shutdownHaskell() ? It worked for me (I am using Visual Studio 7, though). Cheers, Cyril ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Michael, - How to generate an import library at all? Check this out: http://www.haskell.org/haskellwiki/GHC/FAQ#How_do_I_link_Haskell_with_C.2B.2B_code_compiled_by_Visual_Studio.3F - Assuming I have obtained an import library, how to use in the Microsoft world, i.e. how to bridge the gap from .a to .lib? See above. - Is Visual Studio 7 able to process the header files included from the stub header files generated by ghc? Visual Studio 6 has a lot of problems, e.g. it knows nothing about the type long long. I could not make Visual Studio 7 understand those, but I didn't try really hard. - Didn't you have problems with mangled names? Haskell would not understand mangled names. You have to declare the Haskell functions as extern C in the C++ code. This, of course, does not count for functions that are passed to/from Haskell via a function pointer. - What is the principal difference between using the import library and writing one on my own? Does the import library do anything else than loading the library and delegating the calls? I don't know :( Just one more piece of advice: if you can compile your C++ code with gcc, you probably can link it statically to the Haskell code, thus avoiding this DLL nightmare. Hope this helps. Cheers Cyril ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
The memory allocated by the runtime system is never freed.
I've submitted a fix fir this.
-- Lennart
Michael Marte wrote:
Hello *,
before filing a bug report, I want others to comment on my problem.
Maybe it's my fault, not ghc's.
I wrapped up some Haskell modules in a Win32 DLL.
Loading the DLL dynamically (with LoadLibrary) works fine. However,
whether I actually use the library or not, the program (an application
with MFC GUI) crashes upon termination.
To find the reason for the crash, I added a new function for unloading
the DLL using FreeLibrary. FreeLibrary works fine, however the program
crashes when it returns to the main event loop. Interestingly, when I
reload the library (FreeLibrary followed by LoadLibrary) the program
continues working. However, every reload cycle causes the virtual size
of the process to increase by about 300K and the fourth reload fails
with the error message getMBlock: VirtualAlloc failed with: 8 (appears
in a message window) accompanied by many repetitions of the message
Timer proc: wait failed -- error code: 6 (appears on stderr) and
followed by the message getMBlocks: misaligned block returned (again
in a message window). Then the programm crashes.
Development takes place on Windows XP Professional using MS Visual
Studio 6.0 SP 5 and ghc 6.4.1. There are no references from the C++ side
to the Haskell heap. I build the DLL using the command
ghc --mk-dll -optdll--def -optdllFoo.def -o Foo.dll Foo.o Foo_stub.o
dllMain.c
dllMain.c looks as follows:
#include windows.h
#include Rts.h
extern void __stginit_EUzu3820zu85(void);
static char* args[] = { ghcDll, NULL };
/* N.B. argv arrays must end with NULL */
BOOL
STDCALL
DllMain(HANDLE hModule, DWORD reason, void* reserved) {
if (reason == DLL_PROCESS_ATTACH) {
/* By now, the RTS DLL should have been hoisted in, but we need
to start it up. */
startupHaskell(1, args, __stginit_Foo);
return TRUE;
} else if (reason == DLL_PROCESS_DETACH) {
shutdownHaskell();
}
return TRUE;
}
I played around with hs_exit instead of shutdownHaskell, I moved
initialization and clean-up from DllMain to my library loader, nothing
helps. Even doing no clean-up whatsoever does not change the behaviour.
Any ideas?
Michael
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Lennart, do you imply that you have fixed the problem causing the crashes? May I safely assume that DLLs produced by ghc 6.4.2 will not crash upon being freed? I played around a little bit more and found two configurations that do not crash, at least not when freeing the DLL in the course of quitting the application: - compilation with -O, execution with standard heap size - compilation with -O, execution with -M128m. With 64m initial heap space, the problems described earlier occur again :-( Michael Lennart Augustsson wrote: The memory allocated by the runtime system is never freed. I've submitted a fix fir this. -- Lennart ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Cyril, I know the Haskell Wiki page you pointed to; it does not answer my specific questions. The decision which compiler to use is not up to me and, as the Wiki page points out, there is no other way to use Haskell modules from within a Visual Studio C++ compiled application than via a DLL: The Windows distribution of GHC comes bundled with the GCC compiler, which is used as backend. That's why linking Haskell with Visual C++ is no different from linking GCC-generated code with the code generated by Visual C++. One cannot statically link together object files produced by those two compilers, but they can be linked dynamically: an executable produced by Visual C++ can invoke a DLL produced by GCC, and vice versa. Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Michael, Sorry, I might have had wrong assumptions about what you want to do. I presume you have a C++ application compiled via Visual Studio 6 that invokes a Haskell DLL. If that's correct, read on; if not, please tell me again what your setting is. To link your Haskell DLL with the C++ application: 1. Create a .def file for your DLL. Say, your Haskell library is HaskellLib.dll, so your .def file will be HaskelLib.def. Suppose the Haskell finction that you want to call from C++ is myHaskellFunc, then the .def file might look like LIBRARY HASKELLLIB EXPORTS myHaskellFunc 2. Create an import library using Visual Studio's lib.exe: lib /DEF:HaskellLib.def /OUT:HaskellLib.lib 3. Add HaskellLib.lib to your Visual Studio project and link. Cheers, Cyril Cyril, I know the Haskell Wiki page you pointed to; it does not answer my specific questions. The decision which compiler to use is not up to me and, as the Wiki page points out, there is no other way to use Haskell modules from within a Visual Studio C++ compiled application than via a DLL: The Windows distribution of GHC comes bundled with the GCC compiler, which is used as backend. That's why linking Haskell with Visual C++ is no different from linking GCC-generated code with the code generated by Visual C++. One cannot statically link together object files produced by those two compilers, but they can be linked dynamically: an executable produced by Visual C++ can invoke a DLL produced by GCC, and vice versa. Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Did you try to link the DLL statically (i.e. via import library) and
remove the call to shutdownHaskell() ?
It worked for me (I am using Visual Studio 7, though).
Cheers,
Cyril
___
I wrapped up some Haskell modules in a Win32 DLL.
Loading the DLL dynamically (with LoadLibrary) works fine. However,
whether I actually use the library or not, the program (an application
with MFC GUI) crashes upon termination.
To find the reason for the crash, I added a new function for unloading
the DLL using FreeLibrary. FreeLibrary works fine, however the program
crashes when it returns to the main event loop. Interestingly, when I
reload the library (FreeLibrary followed by LoadLibrary) the program
continues working. However, every reload cycle causes the virtual size
of the process to increase by about 300K and the fourth reload fails
with the error message getMBlock: VirtualAlloc failed with: 8 (appears
in a message window) accompanied by many repetitions of the message
Timer proc: wait failed -- error code: 6 (appears on stderr) and
followed by the message getMBlocks: misaligned block returned (again
in a message window). Then the programm crashes.
Development takes place on Windows XP Professional using MS Visual
Studio 6.0 SP 5 and ghc 6.4.1. There are no references from the C++ side
to the Haskell heap. I build the DLL using the command
ghc --mk-dll -optdll--def -optdllFoo.def -o Foo.dll Foo.o Foo_stub.o
dllMain.c
dllMain.c looks as follows:
#include windows.h
#include Rts.h
extern void __stginit_EUzu3820zu85(void);
static char* args[] = { ghcDll, NULL };
/* N.B. argv arrays must end with NULL */
BOOL
STDCALL
DllMain(HANDLE hModule, DWORD reason, void* reserved) {
if (reason == DLL_PROCESS_ATTACH) {
/* By now, the RTS DLL should have been hoisted in, but we need
to start it up. */
startupHaskell(1, args, __stginit_Foo);
return TRUE;
} else if (reason == DLL_PROCESS_DETACH) {
shutdownHaskell();
}
return TRUE;
}
I played around with hs_exit instead of shutdownHaskell, I moved
initialization and clean-up from DllMain to my library loader, nothing
helps. Even doing no clean-up whatsoever does not change the behaviour.
Any ideas?
Michael
--
Message: 2
Date: Wed, 01 Mar 2006 12:06:27 -0800
From: Ashley Yakeley [EMAIL PROTECTED]
Subject: Re: Missing Folder in ghc?
To: glasgow-haskell-users@haskell.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Simon Marlow wrote:
The configure script has mis-detected your GHC version somehow. Could
you look through the output of configure, and see what it says about
GHC?
Nothing special:
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
Canonicalised to: i386-unknown-linux
checking for path to top of build tree...
/home/ashley/Projects/Collected/Haskell/ghc
checking for ghc... /usr/bin/ghc
checking version of ghc... 6.4
checking for nhc... no
checking for nhc98... no
checking for hbc... no
Also look in mk/config.mk, at the value of GhcCanonVersion.
GHC = /usr/bin/ghc
GhcDir = $(dir $(GHC))
GhcVersion = 6.4
GhcMajVersion = 6
GhcMinVersion = 4
GhcPatchLevel = 0
# Canonicalised ghc version number, used for easy (integer) version
# comparisons. We must expand $(GhcMinVersion) to two digits by
# adding a leading zero if necessary:
ifneq $(findstring $(GhcMinVersion), 0 1 2 3 4 5 6 7 8 9)
GhcCanonVersion = $(GhcMajVersion)0$(GhcMinVersion)
else
GhcCanonVersion = $(GhcMajVersion)$(GhcMinVersion)
endif
Maybe you switched GHC versions but didn't reconfigure?
I think the problem is that I called autoconf etc. before I called
darcs-all get, but not after. Calling autoreconf fixed the problem.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
