Mail Archives: cygwin/2003/07/30/23:55:32
Perfect. Thanks a lot.
On Wed, 30 Jul 2003, Igor Pechtchanski wrote:
> Vikram,
>
> Replies inline below.
>
> On Wed, 30 Jul 2003 vikramshrowty AT yahoo DOT com wrote:
>
> > You need this for linking with third-party dlls that dont have a
> > cygwin version.
>
> Yes, you do. The suggestion of omitting msvcrt.dll is bogus.
>
> > 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.
>
> Same (or similar enough) with Cygwin.
>
> > 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.
>
> Correct.
>
> > Could this mean that the non-cygwin dll's entry and exit points are not
> > setup to be called automatically?
>
> No, they should be called properly.
>
> However, note that the two runtimes are sharing the output stream (tty,
> file descriptor, what have you), but aren't sharing the stdio data
> structures. Also, since the main program is linked as a Cygwin program,
> msvcrt's exit() function is *not* called (the Cygwin gcc library one is
> called instead). Thus, the gcc library exit() flushes the buffers of the
> gcc library's stdio implementation, and the msvcrt stdio buffers remain
> unflushed.
>
> Does the above explain things adequately?
> Igor
>
> > 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" <pechtcha AT cs DOT nyu DOT edu>
> > > To: <vikramshrowty AT fastmail DOT fm>
> > > Cc: <cygwin AT cygwin DOT com>
> > > Sent: Wednesday, July 30, 2003 6:03 PM
> > > Subject: Re: linking with non-cygwin dll
> > >
> > > > On Wed, 30 Jul 2003 vikramshrowty AT yahoo DOT com 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
>
>
--
--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/
- Raw text -