C++ standard library ABI

[Jonathan Schilling]

Christophe suggested that the way around the C++ standard library ABI
problem is to move the C++ runtime support library (which includes the
standard library, as well as compiled code support routines) along with
the binaries for the application, when moving from one system to another.

This would mean that multiple C++ RTS libraries might be present on a
system at once (I guess you could refer to them as one "native" and 
zero or more "foreign" libraries).

I think that if we have the C++ RTS travel with the C++ generated code, 
this might allow us to duck a lot of complicated areas - for instance there's 
no need to specify in the ABI exactly what EH tables look like.  The same 
for some other things like array new/delete, ctor/dtor registration, etc.  
Interfaces between compiled code and the RTS in general don't have to be 
specified, but rather just compiled code -> compiled code interfaces 
(the basic object model stuff) and some RTS -> RTS interfaces (e.g. memory
management from multiple systems has to coexist together) and some
RTS -> OS interfaces (e.g. iostreams has to work on top of libc, rather
than depending on anything within it).

I think you could see this as a quasi-OO setup:  generated code has "objects"
which carry with them "methods" in the RTS.  Some objects would be fully
specified in the ABI, while the rest can be overridden in any particular 
implementation.

Jonathan Schilling		SCO, Inc.		jls at sco.com