This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Exceptions workaround for older systems that don't USE_COLLECT2
- To: egcs at cygnus dot com
- Subject: Re: Exceptions workaround for older systems that don't USE_COLLECT2
- From: "Melissa O'Neill" <oneill at cs dot sfu dot ca>
- Date: Tue, 8 Sep 1998 00:04:37 -0700
- cc: Jamie Lokier <egcs at tantalophile dot demon dot co dot uk>, Jeffrey A Law<law at cygnus dot com>, "Melissa O'Neill" <oneill at cs dot sfu dot ca>
- References: <1622.905233552@hurl.cygnus.com>
I wrote:
>>> 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.
... and Jamie Lokier replied:
>> If collect2 doesn't find anything it needs to handle itself (i.e.,
>> exceptions in this case), can it skip the second link and just use
>> the output of the first?
... leading Jeff Law to write:
> Yes. If collect2 finds nothing to do, then it will not perform a second
> link.
>
> However, I'm not sure if the compiler & collect2 are set up to know
> that the linker will handle some set of issues (ctors/dtors) and that
> collect2 is supposed to handle another set of issues (EH frames).
>
> I'd certainly prefer to have something that worked without user
> intervention even if it was a little bit slower at link time. Thus, my
> preference would be to enable collect2 on NeXT boxes.
I agree. Doing the right thing every time has to be preferred over saving
a bit of time for a few cases. Although, as I said earlier, it'd be cool
if g++ could skip the double-link/collect2 business when -fno-exceptions
is in effect, but I doubt anyone is going to take the time to implement
that (after all, 'tis better to fix bugs than add features, IMHO).
Melissa.