From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9831 invoked by alias); 16 Dec 2007 14:18:37 -0000 Received: (qmail 9820 invoked by uid 22791); 16 Dec 2007 14:18:37 -0000 X-Spam-Check-By: sourceware.org Received: from exprod6og103.obsmtp.com (HELO exprod6og103.obsmtp.com) (64.18.1.185) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 16 Dec 2007 14:18:28 +0000 Received: from source ([192.150.20.142]) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP; Sun, 16 Dec 2007 06:17:45 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBGEHgGb003914; Sun, 16 Dec 2007 06:17:43 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBGEHfRC001246; Sun, 16 Dec 2007 06:17:41 -0800 (PST) Received: from namailgen.corp.adobe.com ([10.8.192.91]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Dec 2007 06:17:42 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Sub lib compatibility with g++ Date: Sun, 16 Dec 2007 14:18:00 -0000 Message-ID: References: <131146.25616.qm@web46015.mail.sp1.yahoo.com> From: "John (Eljay) Love-Jensen" To: "Kumar Bhaskar" , 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: 2007-12/txt/msg00290.txt.bz2 Hi Kumar, > I understand that gcc C++ and Sun Studio C++ are not ABI compatible, but = was wondering if there is anything at all I can do to get around this probl= em, short of requesting for a gcc compiled 3rd party lib and/or I having to= change my compiler to Sun Studio. Yes, there is a solution. Since the C ABI is the same on both compilers, y= ou can write a thunking library using the Sun C++ compiler that has C harne= ss routines that call the Sun C++ compiled library methods. And on the GCC side, you can either use those C routines directly, which, e= ffectively, treats that C++ library as if it were a C library (via the thun= king library). Or in addition, you could also write a thunking C++ proxy wrapper on the GC= C side, that behaves as-if it were the objects in the Sun space. Some of the issues that the thunking library has to handle is catching ALL = exceptions, translating (flattening) those exceptions into something that c= an be presented over the C barrier (the Sun-side thunking library). Flatte= ning all vectors, strings, and other Standard C++ Library (STL) objects tha= t are used by the Sun C++ libraries interface (if any). Flattening all non= -POD parameters, and and all returned results. It's a lot of work. I've done it before several times, even once again in = the past couple months. I don't recommend it, if you can avoid it. > I have access to the sun compiler and sun C++ runtime. If you didn't, the challenge would be insurmountable! > For instance - Is it possible to set some options to gcc to indicate - ma= ke use of the Sun name mangling style ? No, GCC doesn't have that option. But it's not just that "mangling is different" (although that is a big fact= or too). The Standard C++ Library (std::vector, std::string, et cetera) is= different too. Iterators are different. Exception handling mechanics are= different. Stack unwinding is different. Parameter passing is different.= Result propagation is different. Inlining is different. Free store (C++= heap) management is different. Streams (fstream, iostream, stringstream) = are different. Non-C POD like bool and wchar_t may be different. All those things are part-and-parcel of the C++ ABI, which is different in = Sun and GCC. HTH, --Eljay