From: mlevedahl@fallschurch.esys.com (Mark Levedahl) Subject: Re: Matlab mex files and cgywin 22 Dec 1998 08:45:35 -0800 Message-ID: <367FA679.C423CCF7.cygnus.gnu-win32@fallschurch.esys.com> References: <199812221159.LAA25568@cheetah.rpms.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matthew Brett Cc: lars.gregersen@private.dk, gnu-win32@cygnus.com Matthew Brett wrote: > ... > I must admit I was hoping to be able to call unix-like functions from > within the dll. I have now, with Mumit Khan's kind help, got Cygwin dlls > to initialise properly when called from a non Cgywin application > (vc++ 4.2). > > This uses the parameter > > --entry __cygwin_noncygwin_dll_entry@12 > > with Mumit's dllwrap utility. > > When I try the same technique for matlab dll generation, > just calling the DLL kills matlab stone dead. I am now at the end of > my ideas of how to pursue this, I really don't have enough experience > of DLL debugging or Cygwin to know what to do next. > ... 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. - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request@cygnus.com" with one line of text: "help".