From: mbrett AT cu DOT rpms DOT ac DOT uk (Matthew Brett) Subject: Re: Matlab mex files and cygwin 22 Dec 1998 12:56:22 -0800 Message-ID: <199812221434.OAA25962.cygnus.gnu-win32@cheetah.rpms.ac.uk> To: mlevedahl AT fallschurch DOT esys DOT com Cc: lars DOT gregersen AT private DOT dk, gnu-win32 AT cygnus DOT com 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".