From:	khan AT xraylith DOT wisc DOT edu (Mumit Khan)
Subject:	Re: Matlab mex files and cygwin
23 Dec 1998 01:14:55 -0800 :
Message-ID:	<199812222252.QAA22297.cygnus.gnu-win32@modi.xraylith.wisc.edu>
References:	<199812221434 DOT OAA25962 AT cheetah DOT rpms DOT ac DOT uk>
To:	mbrett AT cu DOT rpms DOT ac DOT uk (Matthew Brett)
Cc:	mlevedahl AT fallschurch DOT esys DOT com, lars DOT gregersen AT private DOT dk,
	gnu-win32 AT cygnus DOT com

mbrett AT cu DOT rpms DOT ac DOT uk (Matthew Brett) writes:
> 
> 
> 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 abou
> t
> 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 th
> is
> was a known problem, which should have been fixed with B20.1, I think.

It's still a hack! At some point in the future, we should revisit the
issue of Cygwin initialization, but now's not the time. Essentially, there
two recommended entry points for user DLLs using Cygwin:
  
  - __cygwin_dll_entry AT 12 -- for all Cygwin DLLs (other than the Cygwin
    DLL itself of course). This is the default in dllwrap. In the future,
    this name may change to something similar to what MSVC uses, and then
    the linker will also change to use the new name.
  - __cygwin_noncygwwin_dll_entry AT 12 -- This is a hack to support using
    Cygwin DLLs from non-cygwin apps (and only using LoadLibrary, not via
    linking with import library). This was done primarily because of
    problems writing Java JNI's using Cygwin. I essentially tested this
    method with either MSVC apps or Java JNI, but not with Netscape (which
    definitely does not work), nor with Matlab. I should also mention that
    fork probably fails miserably with this hack, and I'm sure a few other
    things do as well.

> Now, late phase, with the new entry point to Cygwin.dll that should initialis
> e
> 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.

As I have noted before, Netscape dies the same horrible death, and it's
quite possibly closely related (even if slightly different). 

I can build a debuggable Cygwin DLL if someone would like to run it
through a debugger and report the results back to me (or give me remote
access to an NT machine with matlab -- but that probably wouldn't work if
Matlab on Windows is a GUI app). Matthew?

> Frustrating!  But, as you say, mingw gives a useful halfway house,

Yes, but unfortunately, lots of POSIX code needs to be rewritten then. 

Regards,
Mumit

-
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 -