From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12882 invoked by alias); 13 Feb 2002 15:37:54 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Received: (qmail 12772 invoked from network); 13 Feb 2002 15:37:49 -0000 Received: from unknown (HELO ligarius-fe0.ultra.net) (146.115.8.189) by sources.redhat.com with SMTP; 13 Feb 2002 15:37:49 -0000 Received: from enterprise-e.rfk.com (216-164-247-145.s2367.apx1.sbo.ma.dialup.rcn.com [216.164.247.145]) by ligarius-fe0.ultra.net (8.8.8/ult/n26500/mtc.v2) with ESMTP id KAA14004; Wed, 13 Feb 2002 10:37:45 -0500 (EST) Message-Id: <4.3.1.2.20020213102635.01e014a0@pop.ma.ultranet.com> X-Sender: lhall@pop.ma.ultranet.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 13 Feb 2002 07:37:00 -0000 To: "Dylan Cuthbert" , "Cygwin@Cygwin. Com" From: "Larry Hall (RFK Partners, Inc)" Subject: Re: cygwin C++ DLLs and inter-operation with M$OFT In-Reply-To: <005d01c1b47d$551d9bc0$2801a8c0@dcuthbert2k> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2002-02/txt/msg00661.txt.bz2 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@rfk.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/