Re: libstdc++ darwin multilibbing support

[Mike Stump <mrs at apple dot com>]

On Feb 16, 2005, at 9:04 AM, Benjamin Kosnik wrote:
> > The most useful non-darwin feature is the
> > addition of support for -fno-exceptions multilib support for 
> > libsupc++.
> This part completely puzzles me, and seems unnecessary: without it,
> -fno-exceptions is fine for compilation.

Unfortunately,
> What you are doing is removing
> definitions with this flag (which may make more sense, but is a
> different idea than the current approach, which is that -fno-exceptions
> should compile, and if people are using it, they aren't using 
> exceptions
> so this stuff doesn't matter.)
> Can you explain why you're doing this again?

As I recall, using std::exception is problematic, as it creates 
unresolved references to what and friends, and those to typeinfo 
things, and those to rtti and friends, and those have stuff that I've 
not untangled yet.  In my case, -fno-rtti is also used, so, the lack of 
the typeinfo stuff doesn't matter to me.

Now, if one multilibs and has exceptions, one can build all the 
routines.  My problem is that I am trying to build the without 
exceptions.  This, is because the flag I'm multilib on doesn't support 
exceptions.

> Especially why guard.cc has overlapping __EXCEPTIONS regions?

?  I think you missed the namespace decls I got rid of.  The first one, 
just recursive_init, not the second one.

> Do you think that __builtin_trap should be used consistently instead 
> of std::abort?

I'm happy with either, abort is slightly more natural, as there are 
already many calls to abort that have to be handled anyway, and 
mechanism that makes them work, makes this instance work.  abort is 
would be more uniform.  If we want wanted to tailor this, we'd need 
support so that all external references to abort in 
lib{gcc,gcc_eh,libstdc++,libsupc++} are mapped, not just one.