From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29362 invoked by alias); 16 Dec 2007 23:52:19 -0000 Received: (qmail 29354 invoked by uid 22791); 16 Dec 2007 23:52:18 -0000 X-Spam-Check-By: sourceware.org Received: from n9.bullet.ukl.yahoo.com (HELO n9.bullet.ukl.yahoo.com) (217.146.182.189) by sourceware.org (qpsmtpd/0.31) with SMTP; Sun, 16 Dec 2007 23:52:10 +0000 Received: from [217.12.4.215] by n9.bullet.ukl.yahoo.com with NNFMP; 16 Dec 2007 23:49:32 -0000 Received: from [216.252.122.219] by t2.bullet.ukl.yahoo.com with NNFMP; 16 Dec 2007 23:49:31 -0000 Received: from [69.147.65.172] by t4.bullet.sp1.yahoo.com with NNFMP; 16 Dec 2007 23:49:31 -0000 Received: from [127.0.0.1] by omp507.mail.sp1.yahoo.com with NNFMP; 16 Dec 2007 23:49:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 612211.42933.bm@omp507.mail.sp1.yahoo.com Received: (qmail 85664 invoked by uid 60001); 16 Dec 2007 23:49:31 -0000 Received: from [71.58.215.254] by web46004.mail.sp1.yahoo.com via HTTP; Sun, 16 Dec 2007 15:49:30 PST X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.158.1 Date: Sun, 16 Dec 2007 23:52:00 -0000 From: Kumar Bhaskar Subject: Re: Sub lib compatibility with g++ To: "John \(Eljay\) Love-Jensen" Cc: gcc-help@gcc.gnu.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <271051.85458.qm@web46004.mail.sp1.yahoo.com> 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/msg00296.txt.bz2 Hi Eljay Many thanks for your note. Indeed does help! I am now considering an approach like this, since in my original deployment I was running with a C program which makes use of a C++ (g++ compiled library) via a dynamically loaded C++ (also g++ compiled) shared object module. This latter module provides the C external linkage via appropriate extern "C" usage to the primary C program. So something like this C program - myprog (compiled with gcc) dynamically loads MODULE A - C++ shared object (g++), with C ABI - which in turn links and uses a g++ compiled C++ lib - say libA.so So far ok, I guess. So from your note, I am now considering expanding this as follows - C program - myprog (compiled with gcc) dynamically loads MODULE A - C++ shared object (g++), with C ABI - which in turn links and uses a g++ compiled C++ lib. (same as before) but also will now dynamically load MODULE B - another C++ shared object (but this time sun compiled), and also with C ABI - which in turn uses the Sun compiled 3rd party C++ lib - say libB.so (libB.so is available only as Sun studio compiled lib) In both cases the C ABIs provides usage of the C++ modules (one g++ compiled and the other sun compiled) from the C prog - myprog (gcc compiled) I am forced to do this, as you say since I can't use MODULE B in g++, since it will make lib calls into libB.so and libB.so is available only in Sun studio compiled version. Do you think this will work out ? One other aspect I am concerned about is that with the above, myprog will eventually make use of both the gcc C++ runtime and the Sun C++ runtime (via the two MODULES A and B which respectively call into libs libA.so and libB.so). Do you see any issues with that ? Also - do you know of any good examples and/or web resources that demonstrate how the "thunking" libs. should be created and provide more info. on the details ? Thanks very much Regards Kumar. ----- Original Message ---- From: John (Eljay) Love-Jensen To: Kumar Bhaskar ; gcc-help@gcc.gnu.org Sent: Sunday, December 16, 2007 9:17:37 AM Subject: RE: Sub lib compatibility with g++ 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 problem, 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, you can write a thunking library using the Sun C++ compiler that has C harness routines that call the Sun C++ compiled library methods. And on the GCC side, you can either use those C routines directly, which, effectively, treats that C++ library as if it were a C library (via the thunking library). Or in addition, you could also write a thunking C++ proxy wrapper on the GCC 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 can be presented over the C barrier (the Sun-side thunking library). Flattening all vectors, strings, and other Standard C++ Library (STL) objects that 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 - make 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 factor 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 ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs