Re: egcs-980315, gen*.c system.h and fatal() using stdarg/varargs

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

  In message <199803262023.PAA14464@caip.rutgers.edu>you write:
  >  > From: Jeffrey A Law <law@cygnus.com>
  >  > 
  >  >   In message <199803251901.OAA02514@caip.rutgers.edu>you write:
  >  >   > 	Getting gcc to cleanly link with libiberty and ironing out all
  >  >   > the related issues is IMHO a non-trivial task.  It would require som
  > eone
  >  >   > taking ownership to see it through.  When this last came up, I don't
  >  >   > think there were any takers.  I could be mis-remembering the
  >  >   > conversation though...  Best check the archive. 
  >  > 
  >  > I doubt it would be as bad as you think.  Most other tools already
  >  > link in libiberty -- gcc is the exception, not the rule.
  >  > 
  >  > I think we tabled it until we were further along with some of the
  >  > warnings/system.h stuff.  Now may be the time to deal with it.
  >  > jeff
  > 
  > 	Well, linking with libiberty would provide the following
  > module to replace vfprintf():
We can always flesh out vfprintf to handle more cases.  That alone
shouldn't be a reason not to use libiberty.

Linking in libiberty to gcc means we can get rid of all the local
copies of xmalloc & friends, vfprintf, alloca, choose-temp, cplus-dem,
getopt, getpwd, pexecute and obstack (and maybe others I can't
remember)

Thus we avoid maintaining multiple versions of all that code.  A
good thing IMHO.

Basically we'd want to do something like

STDLIBS = ../libiberty/libiberty.a

Then add $(STDLIBS) to the link line for cc1*, gen*, gcc, cpp, and
a few other things.

This also takes a step towards being able to link in other library
code that we might need in the future (gettext?)

jeff