delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1999/06/30/21:46:30

Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
From: "Robert O. Morris" <Robert DOT O DOT Morris AT jpl DOT nasa DOT gov>
To: <cygwin AT sourceware DOT cygnus DOT com>
Cc: "Distributed Oceanographic Data Server" <dods-tech AT unidata DOT ucar DOT edu>,
"Robert Morris" <Robert DOT O DOT Morris AT jpl DOT nasa DOT gov>
Subject: Problems using cygwin DLL from Matlab
Date: Wed, 30 Jun 1999 18:43:45 -0700
Message-ID: <000001bec363$27f81160$35a84e89@jpl.nasa.gov>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Hi Group,

  I wanted to pose the real question first - because the size
of the below text might scare everybody off.

Q:  Should I just forget about trying to get any fairly robust
    cygwin/gcc compiled code into a dll that can execute from matlab ?
    What are the _current_ restrictions on just such a dll beast ?

-- details --
  I have created a dll with cygwin/gcc/dlltool - and it
executes from matlab.  I understand there are initialization
issues regarding such a creature.  The code that goes
into the dll is fairly full-featured - this is not
some minimal skeltal code that I'm trying to get
running.  Code that doesn't do much runs fine.  I use
the UNIX emulation layer - not mingw.  I build in a
dll initialization routine (little more than a stub), but
it appears there is not much I can do there to initialize
the dll so that the unix emulation layer it goes through isn't
brain dead as a result of being invoked from within matlab.

  I'm noticing several problems.  Any reference to stdout,
stderr, etc causes matlab to bomb.  For example
fprintf(stdout,"hello world\n").  However printf("hello world\n")
works fine (and this confuses me because 'man printf' on a
unix box tells me it uses stdout also).

  In addition, any popen() call will crash matlab also.
likewise for system().  I downloaded source code from the
cygwin ftp site and notice that popen() calls malloc, but
I don't know if this is the problem.  It appears from 
documentation that anything in the dll for matlab shouldn't
call the memory *alloc() routines directly - but go thru
matlab memory management routines.  However this same popen()
call is fine under matlab for unix.  Perhaps this too is an
dll initialization issue and not a memory management issue.

  Question 2:  I know I can fall-back and resort to using
     mingw via the -mno-cygwin flag.  However I have a large
     number of custom-brewed and web-obtained libraries that
     get linked in (an rpc library, a ipc library, libwww and our own
     stuff to name a few).  If I port the code to compile for mingw,
     I have to also port everything in all these other libraries
     don't I ?  Can't very well have half the dll going thru the
     unix emulation layer and the other half by-passing it.

So, whatcha think - bail out of my current approach or no ?

If you can respond, thanks a bunch !

Rob Morris

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019