Mail Archives: cygwin/1998/12/22/12:56:22
Dear Mark,
> I think the primary problem is a conflict between cygwin's malloc and MATLAB's
> memory allocation: until b20, all my mex files were linked against libcygwin.a
> (hence using cygwin.dll), but I was careful to use mxMalloc, mxCalloc, and
> mxFree instead of malloc, calloc, and free. Using mingw (linking against mscrt),
> I don't need to do this. Obviously, the malloc in mscrt.dll avoids the conflict.
>
> Thus, a partial solution is to recompile those portions of libc and libm that
> are of interest and are missing from mscrt to use mxMalloc, etc. However, a
> complete solution no doubt would require some fundamental changes to cygwin1.dll
> and may be more trouble than it is worth.
I don't know whether it's the memory allocation specifically. In the early
phases of my mex file attempts (which were based on Ton Overbeek's posts about
a year ago, that you mentioned) the mex file dlls were loading, but then
crashing when they executed code involving mallocs etc. This was, I assume,
due to the fact that the cygwin.dll was not being initialised properly, as this
was a known problem, which should have been fixed with B20.1, I think.
Now, late phase, with the new entry point to Cygwin.dll that should initialise
the Cygwin functions including malloc, in b20.1, the mex
file dll just crashes matlab as soon as it is called, even if no malloc-
using code is used. I don't know what this is due to, and don't know how
to pursue it. So close, it seems, and yet so far away.
Frustrating! But, as you say, mingw gives a useful halfway house,
Cheers,
Matthew
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -