On Sun, 2005-05-08 at 22:54 -0700, Zack Weinberg wrote:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> > On Sun, 2005-05-08 at 21:34 -0700, Zack Weinberg wrote:
> >> Ralf Corsepius <[EMAIL PROTECTED]> writes:
> >>
> >> > FWIW: IMO, NO_IMPLICIT_EXTERN_C actually is an OS/libc feature ("Your
> >> > system headers are c++ aware"), therefore it is hardly possible or
> >> > useful to ever use "#define NO_IMPLICIT_EXTERN_C" on "generic" targets
> >> > (*-elf, *-coff etc.).
> >>
> >> I'm going to ask you to think again about that assessment, because
> >> 'implicit extern C' mode is actually trouble if the headers *are* C++
> >> aware
> >
> > The point is: You don't know, because you don't know which kind of
> > headers/libc is using a user is going to build gcc against.
>
> This is true. The question in my mind is which failure mode is worse,
> and honestly I don't know.
Neither do I.
My template answer to such kind of problems is
* Try to detect it with autoconf magic (Probably difficult to implement
for "multi-staged builds", may-be impossible for "one-tree builds")
* In cases detection isn't possible, fall back to "reasonable
defaults" (e.g. --with-newlib, *-rtems*, *-linux* could imply
-DNO_IMPLICIT_EXTERN_C)
* Additionally provide a configure option to enable users to override
autoconf-provided results.
Ralf
