This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: iberty fragments



  In message <19990202005525.01416@liafa1.liafa.jussieu.fr>you write:
  > Unless I'm mistaken, it seems that some Makefile lines are left-over
  > from another age: at some point, xgcc lines and such did not assume
  > libiberty was already built (the LIBS= line does not include libiberty.a on
  > gcc2.8.1), so it made sense to rebuild stuff such as pexecute, getopt, 
  > mkstemp...
Basically yes.  We started including files from libiberty in the form you
find for choose-temp.c, cplus-dem.c and others about 6 months ago.   At that
time we weren't ready to link in libiberty, but we desparately needed to kill
the useless code, bug and patch duplication created by having two copies of
those support files.

We started linking in libiberty about 4 months ago and we'll continue to
kill more of the local functions that are duplicated between libiberty and
gcc (I think the xmalloc family ought to be next on the hitlist :-)  I've
even got patches here to do that :-) :-)

Cleaning up these remnants of the old scheme to avoid the cis a good thing.
Thanks for the patch.  I've installed it.

gcc2 never has (and probably never will) include libiberty.  Kenner has
resisted all attempts to have gcc look more like other GNU packages in
its overall structure.  Sigh.


  > This may have some adverse effects if you change, e.g., cplus-dem.c, and
  > forget to rebuild libiberty, but notice that everything that uses cplus-dem
  > (gdb, for instance) will break anyways. 
Agreed.  I don't see this as a major problem. 


Note for the future.  Please include ChangeLog entries.


jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]