This is the mail archive of the gcc@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: linking gen-protos and fix-header with libiberty


 > From: Zack Weinberg <zack@bitmover.com>
 > 
 > I would like to use the expandable hashtables from libiberty in
 > cpplib.  Doing so reduces code size, code complexity, and runtime
 > memory usage, and has noticeable speed benefits - 38 seconds off the
 > time of a glibc compile (out of 605 seconds spent running the
 > preprocessor).
 > 
 > The difficulty is with gen-protos and fix-header.  Both of these are
 > linked with libcpp.a but not libiberty.a.  Am I correct in thinking
 > that both are "host" programs that can safely be linked with
 > libiberty.a?
 > zw

No, fix-header and gen-protos are "build" programs like genattrtab,
etc.  So they cannot link with libiberty.a until a "build" version of
libiberty is created as part of the bootstrap process.

I will eventually get to this, but I've been very busy for the last
couple of months.  If you want to take a stab, that would be great.

My original approach was to have gcc link both host (and if necessary
build) copies of the libiberty directory tree into the gcc directory
and rebuild them at each stage.  The reason I did it this way was to
handle a case on Irix6 where the ABI changed between stage1 cc and
stage2 gcc causing it to be unable to link with the libiberty.a built
at the top level directory.  I solved the libiberty.a "host/build"
issue almost as an afterthought.

Jeff wasn't too concerned about the ABI change issue, and I've long
since solved it for myself by using the appropriate flags for stage1
cc to generate a matching ABI for stage2 gcc on Irix6.  So we last
left it where Jeff wanted to have the top level Makefile create a
"build" libiberty if necessary.  I can't seem to find his message in
the web archive (I think because Jeff cc'ed it to
"egcs-patches@cygnus.com" instead of "@egcs.cygnus.com".)

Anyway, I've quoted him below so that you can see what he wants to
have happen in case you want to tackle the Makefile issues.

		--Kaveh


 > From: Jeffrey A Law <law@cygnus.com>
 > 
 >   In message <199812132110.QAA10737@caip.rutgers.edu>you write:
 >   > Jeff,
 >   >
 >   >     As per http://www.cygnus.com/ml/egcs/1998-Dec/0266.html, here
 >   > is my first stab at getting egcs to compile both host and build
 >   > copies of libiberty.a in the gcc dir.  I reused the
 >   > HOST_PREFIX/HOST_PREFIX_1 hack already in use for individual .c.o
 >   > files and extended it to all of libiberty via the symlink-tree
 >   > method from the top level  Makefile.
 >   >
 >   >     Note I haven't actually done a canadian cross, hopefully
 >   > someone with more experience can do one of those.  (E.g., I
 >   > don't know if I need to somehow deduce the flags passed to
 >   > configure and send them along to the subdir libiberty?)
 >   >
 >   >     Another note, I had to nullify AR and RANLIB before calling
 >   > configure since the definition of those variables made no sense
 >   > for libiberty/.
 >   >
 >   >     I'd like to install this as it seems to work for host==build
 >   > in all three cases of: srcdir=='.', srcdir=="relative-path-to-egcs"
 >   > and srcdir=="full-path-to-egcs".
 >   >
 >   >     Comments/feedback welcome.  Okay to install?
 >
 > I think we would be better off attacking this outside the gcc
 > directory.
 >  
 > I suspect the way to do this will be to have something similar to
 > the old xiberty directory which used to build a target-libiberty at
 > the toplevel.
 >  
 > Or better yet, use the same mechanisms we currently do for building
 > the target libiberty in a target specific subdir to build a build
 > specific libiberty in a build specific subdir.
 >  
 > ie, in the build tree we would have
 >  
 > libiberty -- host version of libiberty
 > build-alias/libiberty -- build version of libiberty
 > target-alias/libiberty -- target version of libiberty
 >  
 > We would always build build-alias/libiberty, even when host ==
 > build.  That way gcc can just link in build-alias/libiberty.a
 > without having to conditionalize the code worse than it already is.
 >  
 > This also provides infrastructure that other projects can use.  For
 > example it might be useful one day to link bison & flex with the
 > build version of libiberty if it allows the maintainers to clean up
 > those distributions.
 >  
 > Or my favorite -- fast-fixincludes :-)
 >  
 > I'm on-board with the idea that we need to distinguish host vs
 > build libiberty, the only question now is how to do it :-)
 > jeff
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions


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