Subject: Re: linking with non-cygwin dll
From: [email-masked]
To: Martin Gainty <[email-masked]>
Cc: [email-masked]
Date: Wed, 30 Jul 2003 18:46:34 -0700 (PDT)

You need this for linking with third-party dlls that dont have a
cygwin version. I was looking through some documentation for the MKS
toolkit (it's like a commercial alternative to cygwin) and according
to it, a program that uses the MKS c-library can link with dlls that
are in turn linked to msvcrt.dll (or whatever provides the msft c
library). It seems that as long as you dont try to link in both the
c-libraries simultaneously into the same program or dll, it is not
a problem.

So, for code in the dll, stdout refers to msft::stdout whereas in the
main program, it refers to cygwin::stdout. I was wondering if this is
an issue of gcc not setting things up to properly call the dll's entry
and exit functions or something like that. When you are linking the
main program you do ...

> gcc -Wall  -g -o test.exe test.c -L. -lgcc -ldll

Note the absence of the -mno-cygwin, because your main program is a
cygwin program. Could this mean that the non-cygwin dll's entry and
exit points are not setup to be called automatically?

On Wed, 30 Jul 2003, Martin Gainty wrote:

> I would go so far as to suggest taking MSVCRT.dll off the path altogether
> After all why have 2 runtimes?
> -Martin
> ----- Original Message -----
> From: "Igor Pechtchanski" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, July 30, 2003 6:03 PM
> Subject: Re: linking with non-cygwin dll
> 
> 
> > On Wed, 30 Jul 2003 [email-masked] wrote:
> >
> > > Hi,
> > >         I had posted a query earlier about a cygwin program linking
> > > with a non-cygwin dll. Based on the very helpful responses and some
> googling
> > > around, I learnt that this is possible. But...
> > >
> > > heres a main.c that links with cygwin1.dll
> > >
> > > int main(void)
> > > {
> > >   printf("CYGWIN\n");
> > >   test_dll();
> > >   return(0);
> > > }
> > >
> > > where test_dll is in a dll compiled with -mno-cygwin and is defined
> > > like this...
> > >
> > > __declspec(dllexport) __stdcall void test_dll(void)
> > > {
> > >   printf("MSFT %d\n",i);
> > >   fflush(stdout);
> > > }
> > >
> > > This works perfectly. But, notice the fflush. If this is removed,
> > > "MSFT" doesnt get printf'ed. I assuming that this is because the
> > > stdout buffer in the microsoft c-library isnt getting flushed
> > > automatically at program exit.
> > >
> > > Any ideas on why?? ..and how to remedy this??
> > > --Vikram
> >
> > Well, gcc links the Cygwin executable with its own C runtime.  MSVCRT is
> > another C runtime.  So, when you call the DLL, you have 2 C runtimes
> > competing for the same output stream.  This can't be good (in fact, the
> > results are unspecified, IIRC).  Thus, the simple remedy is: don't do
> > that.  Either only use one runtime for output (whichever one), or fflush
> > and pray.
> > Igor
> > --
> > http://cs.nyu.edu/~pechtcha/
> >       |\      _,,,---,,_ [email-masked]
> > ZZZzz /,`.-'`'    -.  ;-;;,_ [email-masked]
> >      |,4-  ) )-,_. ,\ (  `'-' Igor Pechtchanski, Ph.D.
> >     '---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!
> >
> > "I have since come to realize that being between your mentor and his route
> > to the bathroom is a major career booster."  -- Patrick Naughton
> >
> >
> > --
> > Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> > Problem reports:       http://cygwin.com/problems.html
> > Documentation:         http://cygwin.com/docs.html
> > FAQ:                   http://cygwin.com/faq/
> >
> >
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:       http://cygwin.com/problems.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 
> 

-- 
--Vikram

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/