Re: [Gnustep-cvs] Commit Update

[Alexander Malmberg]

David Ayers wrote:
> > +     * configure.ac: Detect native exception handler support in the
> > +     compiler, and set HAS_OBJC_EXCEPTIONS to yes if it's there.
> > +     * configure: Regenerated.
> > +     * config.make.in: New variable HAS_OBJC_EXCEPTIONS.
> > +     * common.make: If HAS_OBJC_EXCEPTIONS is set, add
> > +     -fobjc-exceptions to the ObjC flags.
> > +
> 
> Hello Nicola,
> 
> I'm not sure we want to do this in this way.  Mixing -fobjc-exceptions
> code with old style exception code will most likely cause serious
> problems.  (AFAICT, unlike Apple, we actually use GCC's native exception
> handling features already where as Apple still does setjmp/longjmp for
> the new constructs for backward compatibility.)

True. The setjmp/longjmp exception handling _could_ be made to work with
our current exception system, but it'd take tons of work. The recent
changes haven't affected that. The unwind-based exception handling is
incompatible in all kinds of ways.

> An update in gcc
> shouldn't require you to recompile everything.  I think we should only
> activate the feature if explicitly requested by the user as a
> ./configure option.

Agreed. (Also, merely adding -fobjc-exceptions seems to have a
significant effect on code size.)

Also, the detection currently uses AC_COMPILE_IFELSE, which just checks
that the code compiles. As far as I can tell, 3.4 has the parser bits of
this, which might be enough to compile the code, even though 3.4 doesn't
have the libobjc support or working code generation for it. Has anyone
tested this on 3.4.0? Either way, a run test would be safer
(AC_RUN_IFELSE).

- Alexander Malmberg