public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kumar Bhaskar <akumargolf2000@yahoo.com>
To: "John \(Eljay\) Love-Jensen" <eljay@adobe.com>
Cc: gcc-help@gcc.gnu.org
Subject: Re: Sub lib compatibility with g++
Date: Sun, 16 Dec 2007 23:52:00 -0000	[thread overview]
Message-ID: <271051.85458.qm@web46004.mail.sp1.yahoo.com> (raw)

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 <eljay@adobe.com> 
To: Kumar Bhaskar <akumargolf2000@yahoo.com>; 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

             reply	other threads:[~2007-12-16 23:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-16 23:52 Kumar Bhaskar [this message]
2007-12-17  0:24 ` John (Eljay) Love-Jensen
  -- strict thread matches above, loose matches on Subject: below --
2007-12-16  8:20 Kumar Bhaskar
2007-12-16 14:18 ` John (Eljay) Love-Jensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=271051.85458.qm@web46004.mail.sp1.yahoo.com \
    --to=akumargolf2000@yahoo.com \
    --cc=eljay@adobe.com \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).