Has anyone looked at the possibility of donating to g++ code that would enable it to be compatible with the Sun C++ ABI on Solaris? Is it technically feasible to modify g++ to handle ABI alternatives for C++ (which probably include but may not be limited to symbol mangling, virtual function handling), preferably not just as a build option, but as a runtime choice between the two (with a configurable default)? What else in the GNU toolchain would have to be aware of those changes for all of it to work as it does on other platforms, so that no new porting difficulties would be introduced?
Are the elements of the Sun C++ ABI that differ from the g++ ABI even (a) all identified and (b) openly documented somewhere, such that even if the needed code is encumbered, someone could work on such a project without needing that code? Last but not least, has there been any progress towards standardizing a C++ ABI? Workarounds are fine, but IMO this problem should be dealt with in a way that makes them unnecessary, and makes the compilers capable of being as fully capable of having their object files linked for C++ as they are for C. That, plus increasing gcc/g++ source compatibility support that I think I've already heard of working its way into the Sun compilers, should let them be used more often interchangeably, to give the best results. For SPARC, as long as one is willing to use gcc ABI (where they differ), http://cooltools.sunsource.net/gcc/ presumably lets one compete the Sun optimizer against the one in regular gcc. But that doesn't fully address compatiblity for those who already depend on the Sun C(++) ABI, nor does it address competing optimizers for x86 (although the problem probably isn't so serious there, since gcc for x86 has presumably gotten a _lot_ more attention at generating efficient code than gcc for SPARC). This message posted from opensolaris.org
