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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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++
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.
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
21 matches
Mail list logo
