Why does this now work?

Why does this now work?

[murray]

With gcc 3.2 (binary downloaded from sunfreeware, native ld and as), I
can now build programs against a 3rd party library which I am certain
was compiled in 1999 with SUN Workshop C++ 4.2 (which is the only
compiler the vendor will suppport in the use of their library). Previous
versions of gcc failed in various odd ways (it might have been me being
odd, but I never knew). The gcc executables are slightly smaller but
give results and times identical to executables built with Sun Workshop.
I am using an Ultrasparc 1 running Solaris 2.6.

I am mystified as to what I can get away with, given I was still
expecting some incompatibility in the process (name mangling at the
least). Can anyone point me to some wisdom on this matter?

Thanks
Graeme

Re: Why does this now work?

[Eljay Love-Jensen]

Hi Graeme,

If the libraries are C libraries, the C ABI is well defined.  I'm surprised 
that GCC 2.95 would have issues.

If the libraries are C++ libraries -- have and propagate exceptions, don't 
use extern "C", rely on Sun's C++ ABI (which is non-standard, as there 
ISN'T a C++ ABI standard at the moment) -- then I'd be surprised if you 
could get the Sun C++ object code to link with GCC C++ object code even in 
trivial C++ examples.

Are these libraries 1) a .so and .h files (dynamic linkage), or 2) a .a and 
.h files (static linkage), or are they 3) source code that you compile 
yourself?

If #3, then I'm somewhat surprised that they DIDN'T work with GCC 
2.95.  Although, GCC 2.95 was close to compliance with the 1995-1996 C++ 
draft spec (a moving target), and GCC 3.2 is very close (if not dead on) to 
the C++ ISO/IEC 14882:1998 spec.

Wasn't the GCC quote, "As close to the ISO/IEC 14882:1998 spec as possible, 
and no closer"...?  *grin*

Anyone implement "export" yet?  Other than Comeau C++, I presume.

--Eljay