Sub lib compatibility with g++

Sub lib compatibility with g++

[Kumar Bhaskar]

Hello 

I am trying to make use of a 3rd party archive C++ library that was compiled with Sun compiler. This is evident from the some of the name mangling that I can see within the .o files. I do not have the source code for this lib. 

I am using my C++ program to call into this library but my code is being compiled with gcc/g++. 
Clearly my program doesn't link successfully with the 3rd party lib. (due to diffferences in name mangling) 

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. 

I have access to the sun compiler and sun C++ runtime. 
For instance - Is it possible to set some options to gcc to indicate - make use of the Sun name mangling style ? 

Would greatly appreciate some help, even if there is no way to do this. I can then pursue other means of using this 3rd party lib - so in that regard want to be able to rule out that I cannot use the gcc/g++ compiler. 

Thanks


      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

RE: Sub lib compatibility with g++

[John (Eljay) Love-Jensen]

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

RE: Sub lib compatibility with g++

[John (Eljay) Love-Jensen]

Hi Kumar,

> Do you think this will work out ?

It can work.  It won't be fun.

> 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 ?

The key issue is making sure that symbols are properly bound, such that the Sun C++ only binds to Sun C++ symbols by the loader, and GCC C++ only binds to GCC C++ symbols by the loader.

Another solution is to use separate processes, and then communicate to the Sun C++ "slave" process (assuming that's the one you'd make slave) through RPC or IPC or a listening socket.  That makes for a very clean demarcation between the GCC C++ process and the Sun C++ process.

> 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 ?

No, I'm not sure.

I learned it by working with Netwise RPC technology, before Microsoft acquired them.

Another good example of providing an opaque C interface to an object-oriented implementation is Apple's Carbon.  X11 is also a good example of object-oriented design, implemented in C (which could have been written in C++ -- maybe it is in some implementations).

If you only have one top level class to expose, say SunFoo...

class SunFoo
{
public:
    SunFoo();
    ~SunFoo();
    void DoSomething();
    void OtherSomething(std::string const&);
};

...you're thunking C interface will have to provide...

Initialize();
Terminate();
int ExceptionOccurred();
typedef struct OpaqueSunFoo* SunFoo_t;
SunFoo_t SunFooConstruct();
void SunFooDestruct(SunFoo_t);
void SunFooDoSomething(SunFoo_t);
void SunFooOtherSomething(SunFoo_t, char const*);

You'll need to have a "cookie" that represents a SunFoo on the GCC side.  Something like "typedef struct OpaqueSunFoo* SunFoo_t" can work well.

You'll need to "revive" all C-style parms into the SunFoo's C++ object parms.

You'll need to carefully manage memory allocation so the right side of the fence has ownership & responsibility to delete/free things.

You'll need to catch all exceptions and have some facility to query if an exception occurred.

If your Sun C++ has lots and lots of objects and methods that you want to expose... then that can be a considerable (and very unpleasant) challenge.

HTH,
--Eljay

Re: Sub lib compatibility with g++

[Kumar Bhaskar]

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