Re: sjlj exceptions

[Marc Espie <espie at quatramaran dot ens dot fr>]

In article <20010314090321W.mitchell@codesourcery.com> you write:
>>>>>> "Mike" == Mike Stump <mrs@windriver.com> writes:
>
>    >> What do folks think about making this choice a configure flag
>    >> instead of a runtime flag?  Say --with-sjlj-exceptions to
>    >> override the default that gcc would have otherwise chosen. the
>    >> libraries would have an autoconf check for what style gcc uses
>    >> and build accordingly.

>    Mike> It was only meant as a compiler developement tool.  The
>    Mike> simplest of things would work, but as you note, once you hit
>    Mike> the library, one had no hope of things working.

>I certainly think that making users specify this at configure-time is
>reasonable.  And like Mike, I see no reason to multilib it.  Just make
>`--with-sjlj-exceptions' build with that kind of exceptions, instead
>of the ordinary kind everywhere.  If you were already going to
>multilib, you get the same multilibs -- but with the other kind of
>exceptions.

I think this might make some sense to have a marker that this was built
--with-sjlj-exceptions. There will be no change in the host triplet, but
putting stuff under a specific sjlj subdirectory (in effect, handling this
as though it were multilibbed, even though there is just one flavor of it)
might make sense.

The main point against multilib in this case is rebuilding the same libraries 
twice, right ?

Well, assuming you are debugging sjlj vs. newer exceptions, being able
to have both sets of libraries coexist peacefully (as in, you have the 
older stuff installed --with-sjlj-exceptions, and you're rebuilding without
sjlj-exceptions) does make some sense.