Re: libiberty x libgcc2 (cp-demangle.c and dyn-string.c)

[Jeffrey A Law <law at cygnus dot com>]

  In message <orya2ubll8.fsf@guarana.lsd.ic.unicamp.br>you write:
  > On Jul 22, 2000, Jason Merrill <jason@redhat.com> wrote:
  > 
  > >>>>>> Alexandre Oliva <aoliva@redhat.com> writes:
  > >> Some libiberty sources that are used while building libgcc2 shouldn't
  > >> include libc headers unconditionally; they should honor inhibit_libc,
  > >> because GCC_FOR_TARGET can't find newlib (or glibc) headers.
  > 
  > > I thought inhibit_libc meant "don't assume there is a C library", not
  > > "don't assume we can find the C library headers".
  > 
  > Might well be.  But I'm currently building a newlib-enabled
  > --target=sh-elf toolchain, and it does define inhibit_libc.  It also
  > defines IN_LIBGCC2 and IN_GCC; maybe using some of these would be
  > better?
  > 
  > Anyway, the patch I'm about to propose will obviate this one, at least
  > in case newlib or glibc are in use.
inhibit_libc is a particularly poor name.

inhibit_libc inhibits the inclusion of certain functions in libgcc on the
assumption that they will be provided by the target system's libc.

jeff