This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: loading multiple C++ runtimes but not mixing ABIs?
On 9/4/07, Ken Raeburn <raeburn@raeburn.org> wrote:
> On Sep 4, 2007, at 13:26, Lawrence Crowl wrote:
> > On 8/31/07, Ken Raeburn <raeburn@raeburn.org> wrote:
> >> Is the usual procedure, then, to just require that the application
> >> builder consistently use the same compiler implementation for
> >> everything?
> >
> > Yes, though this is not as onerous as you might think.
>
> That one I would think would be relatively easy. It's the vendor-
> supplied libraries case I'm concerned about.
Yes, but they use the reference compiler (or a close approximation).
>
> >> This would be particularly annoying if the library in
> >> question were being provided by the OS vendor, and not always
> >> downloaded and built by the application builder.
> >
> > On systems with strong binary compatibility guarantees, shipping
> > binaries with an agreed upon base compiler is not terribly difficult.
> > Generally, there is one compiler associated with the OS that serves
> > as the reference compiler, and all others must conform. On
> > Windows, that compiler is Microsoft's. On Solaris, that compiler
> > is Sun's. On HPUX, that compiler is HP's.
>
> If exceptions and such are as much of a problem as it sounds, I guess
> they aren't doing very well at conforming?
I think I was unclear. Avoiding exceptions is only necessary if you
wish to avoid any dependence on the C++ run-time library. If the
dependence is acceptable, then exceptions are fine as long as you
use the stable reference compiler.
> > On Linux, the binary
> > story is not as strong, but the compiler is GNU's.
>
> I remember there being quite a mess around the pre-gcc-3 days because
> of ABI changes in the GNU compilers, though I don't know if it
> affected all libraries using C++ at all, or just those exposing use
> of C++ in their APIs. Just the sort of thing I'd want to avoid....
Certainly the latter, but the former is possible with unstable C++
runtime libraries.
--
Lawrence Crowl