Re: Exceptions workaround for older systems that don't USE_COLLECT2

["Melissa O'Neill" <oneill at cs dot sfu dot ca>]

I wrote:
>> Received wisdom states that you're on a system that doesn't need
>> to ``USE_COLLECT2'', you should make sure you're running a recent
>> version of GNU ld if you want exception support to work (at least
>> if it's using __throw for exceptions).
>> 
>> However, under NEXTSTEP 3.3 one can't install a recent GNU ld,
>> because GNU ld doesn't support NEXTSTEP's object format. But,
>> because NEXTSTEP's ld is smart enough to grok constructors and
>> destructors, EGCS 1.1 (and every earlier release) isn't set to
>> ``USE_COLLECT2''. Net result: while static constructors and
>> destructors work fine, exceptions don't.

... and Jeffrey A Law replied:
> Seems to me we ought to enable collect2 on these systems.

That's certainly a possible solution and likely the best compromise.
The downside is that collect2 would do static constructor/destructor
handling when NeXT's ld is happy to handle it.  And, since many C++
programs don't use exceptions at all, the overhead of always using
collect2's double-link strategy for those common cases seems a little
burdensome.

But, I reckon that having collect2 deal with exceptions, constructors
and destructors is the only practical way to avoid race conditions
with exceptions raised in static constructors.

I think that preferable solution would be to have collect2 for
NEXTSTEP do everything itself when -fexceptions is in effect, but use
NeXT's ld when -fno-exceptions is active. But, all that seems like a
lot of work for a diminishing platform.

    Melissa.

P.S. The perl script I posted is good enough for my C++ projects, though
and means I only incur the extra link overhead when I need it. YMMV. (It
was also the fastest way to confirm that an uninitalized frame info
table was the point of failure.).