From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10795 invoked by alias); 22 Aug 2008 23:57:56 -0000 Received: (qmail 10781 invoked by uid 22791); 22 Aug 2008 23:57:55 -0000 X-Spam-Check-By: sourceware.org Received: from mail01.tanner.com (HELO mail01.tanner.com) (70.137.39.20) by sourceware.org (qpsmtpd/0.31) with SMTP; Fri, 22 Aug 2008 23:57:20 +0000 Received: (qmail 18551 invoked from network); 22 Aug 2008 23:57:15 -0000 Received: from unknown (HELO exchange01.tanner.com) (192.168.104.27) by mail01.tanner.com with SMTP; 22 Aug 2008 23:57:15 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: extern "C" From command line Date: Sat, 23 Aug 2008 01:38:00 -0000 Message-ID: In-reply-to: <48AE1E8A.12ADDE12@dessent.net> References: <200808191257.28899.zepm@gatech.edu> <48AE1E8A.12ADDE12@dessent.net> From: "Seyran Avanesyan" To: Cc: X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2008-08/txt/msg00241.txt.bz2 Brian Dessent wrote: > Please don't hijack threads; start a new thread.=20=20 Thanks for correcting me.=20 > The mangling is there for a reason. If you exported a function with > C++ > linkage but without its name mangled then it's very likely that you > could call it from a compiler with a different C++ ABI, such as MSVC, > and that would fail. Mangling prevents this, because it requires that > to call the function you have a compiler with compatible ABI. The functions are going to be exported from a Dll, which is going to be done using MinGW. Is that still requires that client of that Dll be compiled with MinGW?=20 > If your complaint is simply that you don't want to put mangled names in > the .def file, then I must ask: why use a .def file at all? It's > usually not needed. The GNU linker has auto-export enabled by default > which causes all symbols to be exported if __declspec(dllexport) is not > used anywhere. And if __declspec(dllexport) is used, then the source > itself already controls what functions to be exported so the .def file > is extraneous. gcc -x c++ source.cpp -o source.o gcc -shared -o source.dll my_source.o source.o I'm exporting just two functions from "my_source.o" (which I have access to, and they have __declspec(dllexport) and extern "C"). There are many other global functions in "my_source.o" which is used from "source.o", but not need to be exported from the resulting Dll. I needed .def file to export all global functions from "source.o" to not use -export-all feature (because it will export all globals from both modules regardless of __declspecs.) And I'm getting this .def file by using dlltool (MinGW component.) The problem is I need to MinGW compile a Dll as C++ not as C, and call exported functions from MSVC compiled application.=20 Thanks, Seyran