This is the mail archive of the
mailing list for the Cygwin project.
Re: cygwin gcc DLLs loaded by Visual C++ crashing
- From: "Dylan Cuthbert" <dylan at q-games dot com>
- To: "Larry Hall \(RFK Partners, Inc\)" <lhall at rfk dot com>,"Cygwin at Cygwin dot Com" <cygwin at cygwin dot com>
- Date: Thu, 14 Feb 2002 12:06:12 +0900
- Subject: Re: cygwin gcc DLLs loaded by Visual C++ crashing
- References: <email@example.com>
Thanks for the reply.
I have searched the mailing lists high and low and as far back as 1998 and
there are some references to this problem and some solutions, yet there are
no definitive "this works" type responses ( in fact, almost all the
responses I found seemed like temporary hacks ) and it would take a long
time to try implementing all the various solutions listed with no guarantee
they work. Maybe I'm searching with the wrong string - I'm looking under
subjects such as "initializing cygwin from dll" or "initialize cygwin dll",
am I missing some important keyword?
The closest thing I have found is probably the "use LoadLibrary" to load the
cygwin.dll manually and then calling cygwin_dll_init(), but even that
crashes according to
http://sources.redhat.com/ml/cygwin/2001-08/msg00790.html (couldn't find
any response confirming or denying this mail)
Then there's the (from 1998) use the "crt0.o" to link with and create a
dummy thread and a main() which doesn't exit - this seems like a complete
hack. I think this is probably the wrong direction, right?
Then there's this comment from cgf -
http://sources.redhat.com/ml/cygwin/2000-12/msg00366.html which seems to say
that cygwin_dll_init() is the way to go.
However, when I try using cygwin_dll_init I get an exception error, I
couldn't find any definition of a function called cygwin_dll_init in any
header file or library file anywhere so I force-ably extern'ed it. Does it
really exist, if so, where?
Any ideas, anyone?
Q-Games, Dylan Cuthbert.
----- Original Message -----
From: "Larry Hall (RFK Partners, Inc)" <firstname.lastname@example.org>
To: "Dylan Cuthbert" <email@example.com>; "Cygwin@Cygwin. Com"
Sent: Thursday, February 14, 2002 12:34 AM
Subject: Re: cygwin C++ DLLs and inter-operation with M$OFT
> At 05:58 AM 2/13/2002, Dylan Cuthbert wrote:
> >To anyone who can help,
> >We've been having some fun creating DLLs that need to be loaded by some
> >Visual C++ code. The code in the dll itself, ie. the interface is C so
> >there aren't any name mangling problems. However, using v3.0.3 of GCC we
> >get unresolved symbol errors for any libstdc++ we do within the dll.
> >errors don't occur after using the -V 2.95.3-5 option to gcc to revert to
> >the originally packaged compiler - I had a good poke around but I
> >work out why the symbols couldn't be resolved.
> >Anyway, after reverting to 2.95.3-5, our test code compiles but when we
> >any cygwin dll code (from the VS application) we get an exception error
> >cygwin1.dll - if the code uses any stdlib type stuff (such as memory
> >allocation, printf etc). There is no C++ code in there at all now.
> >I've read through the faqs and documentation and searched the mailing
> >but I can't find any fixes for this problem (although a couple of other
> >people do mention it). Is there just some obvious initialisation stuff
> >missing somewhere?
> Probably. This has been mentioned in the past. You want to look at the
> Cygwin initialization code to see what happens there. It needs to happen
> when the DLL is loaded by non-Cygwin apps as well. Some of this may come
> for free at this point. Discussion of this issue was quite some time ago
> (check the developer email archives if you're curious) and I don't
> the final consensus and/or changes. But, the archives should have the
> history and the startup code should give you a hint of the current state.
> Larry Hall firstname.lastname@example.org
> RFK Partners, Inc. http://www.rfk.com
> 838 Washington Street (508) 893-9779 - RFK Office
> Holliston, MA 01746 (508) 893-9889 - FAX
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html