libExbridge - does it work ?
We are migrating from the C++ 4.2 compiler to SunStudio 11 on Solaris 8. We have vendor libraries which were built with the 4.2 compiler and have no access to source or newer versions. One library is just C while the other is C++. There is an additional vendor library that is built with the 5.x compiler in standard mode. Our application code compiles in both standard and compatibility mode.
I think that the C vendor library will link in just fine. Is this correct ?
For the C++ vendor library I am trying to use the libExbridge detailed in the Migration Guide. I just created a simple test scenario. I create a simple class - Apple. If I compile in standard mode, it links in just fine and everything works. If I compile in compatibility mode, the link get undefined symbols for the Apple class, whether I specify the -lExbridge or not. Without the -lExbridge I also get undefined for Iostream_init.
Using nm on Apple.o in compatibility mode I get
U __0FEendlR6Hostream
00000198 t __0FT__STATIC_DESTRUCTORv
00000168 t __0FU__STATIC_CONSTRUCTORv
000000d8 T __0fFAppleKcheckPricev
U __0fOunsafe_ostreamGoutstrPCcTB
00000048 T __0oFApplectv
U __0oNIostream_initctv
U __0oNIostream_initdtv
00000010 t __SLIP.INIT_A
U cout
00000000 d iostream_init
using nm on the calling object file and grepping Apple I get
[156]| 0|0|FUNC |GLOB |0|UNDEF |__1cFApple2t6M_v_
[155]| 0|0|FUNC |GLOB |0|UNDEF |__1cFAppleKcheckPrice6M_v
you can see the symbols do not match - therefore the link error. The calling object file was created in standard mode. If Apple is compiled in standard mode the nm outputs match so far as mangled names are concerned.
So my questions are
1) am I missing something ? is what I want even doable ?
2) what is libExbridge supposed to do - map mangled names somehow ?
3) my question above - will C code created with the 4.2 compiler link in and work just fine with 5.x compiler ? A small test seemed to confirm this.
Thanks in advance.
[2095 byte] By [
tvel10a] at [2007-11-27 9:15:40]
# 1
C code uses the stable Solaris ABI, and there are usually no issues in using old binaries with new code. Studio 11 C by default compiles in C99 mode. You might want to use the -xc99=none option.
C++ code:
Be sure to read the complete section in the Migration Guide on mixing binary modes. It explains the full set of requirements, *all* of which must be met.
The naming differences you see reflect the name mangling used by the C++ 4.2 ABI versus the name mangling used by later compilers in standard mode. Name mangling is the least of the problem areas, however. The layout of classes and vtables is different, RTTI data is different, exception handling is different, among other differences. As explained in the Migration Guide, mixing code can work only if no C++ types, objects, or functions are in the interface between the library and main program.
The purpose of libExbridge is to allow old-style exceptions to co-exist with new-style exceptions, but only under the restricted circumstances listed in the Migration Guide.
If you can't meet *all* of the listed restrictions, you will not be able to mix binaries from C++ 4.2 with C++ binaries compiled by any of the more recent compilers in default standard mode .
In any event, our strong recommendation is not to attempt to mix modes. The two viable options are these:
1. Use Studio 11 C++ in -compat=4 mode. It generates code compatible with C++ 4.2. You will not be able to use the C++ Standard Library, or any C++ features introduced by the C++ Standard. The Migration Guide lists the differences in source code accepted by C++ 4.2 and accepted by Studio 11 C++ in -compat=4 mode.
2. Recompile the old C++ code with Studio 11 in standard mode. This is the recommended solution. The Migration Guide lists all the problems you might encounter when compiling old source code in standard mode, and suggests solutions for each of them.
Apparently you don't have access to the old source code. In that case, you must weigh the near-term costs of trying to use code for which you have no sources and which is not compatible with standard C++, with the costs of abandoning the old library and acquiring or writing a replacement.
Long-term, the only viable solution is to replace the old code and compile in standard mode.
# 2
ok. So libExbridge is really intended to handle exception handling issues.
I still don't understand how you could even link the things together given the name mangling issue, but it sounds like that is a bad road to head down in general.
So just to clarify, regarding the plain C code. Old plain C code should be able to link just fine with C++ code compiled in standard mode ?
Thanks.
# 3
> ok. So libExbridge is really intended to handle
> exception handling issues.
libC.so.5 (used by C++ 4.2) and libCrun.so.1 (used by C++ 5.x) have exception-handling routines with the same names that do different things. We did not consider this a problem because we never intended for old and new C++ binaries to be linked together. Some customers insisted on doing so, so we created libExbridge to interpose on the exception-handling routines and route the old-style and new-style exceptions to the right handler. You still can't let an exception cross the boundary.
>
> I still don't understand how you could even link the
> things together given the name mangling issue, but it
> sounds like that is a bad road to head down in
> general.
Suppose you have a class T compiled by both old and new compilers. The mangled names of T's member functions will be different, so you can't link references to those functions across the boundary. But since the representation of T objects and the calling sequence for T's constructors and destructors is likely to be different anyway, allowing the code to link would result in a program that doesn't run correctly. Name mangling is different in part to prevent linking code that is incompatible for other reasons.
But if T is used only on one side of a library boundary, there is no issue. The only code that uses T is all compiled in the same mode.
If the interface to a library is a C interface (callable from a C program, for example), the library could contain C++ code compiled in a different mode and still link to the main program. There are other issues that can bite you, however, listed in the Migration Guide.
There are so many things that can go wrong that we recommend not going down that path.
>
> So just to clarify, regarding the plain C code. Old
> plain C code should be able to link just fine with
> C++ code compiled in standard mode ?
Right. The C interfaces and ABI did not change.
