Mail Archives: cygwin/2002/02/13/22:06:58
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.
http://www.q-games.com
----- Original Message -----
From: "Larry Hall (RFK Partners, Inc)" <lhall AT rfk DOT com>
To: "Dylan Cuthbert" <dylan AT q-games DOT com>; "Cygwin AT Cygwin. Com"
<cygwin AT cygwin DOT 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.
These
> >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
couldn't
> >work out why the symbols couldn't be resolved.
> >
> >Anyway, after reverting to 2.95.3-5, our test code compiles but when we
call
> >any cygwin dll code (from the VS application) we get an exception error
in
> >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
list
> >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
I'm
> >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
remember
> 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 lhall AT rfk DOT com
> 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
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -