This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch: create a BUILD libiberty.a
- To: zack at wolery dot cumb dot org
- Subject: Re: Patch: create a BUILD libiberty.a
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Tue, 15 Feb 2000 10:59:29 -0500 (EST)
- Cc: egcs-patches at egcs dot cygnus dot com
> From: Zack Weinberg <zack@wolery.cumb.org>
> >
> > I agree with you about MALLOC, however ALLOCA is set and used in many
> > config files. There is currently no alloca machinery in
> > gcc/configure.in to set HAVE_ALLOCA_H, nor does any file honor it. So
> > it would take a bit to get alloca set up and clean up the xm-alloca.h
> > turds in configure.in and the ALLOCA vars in the config/ dir.
>
> Well, at least get you could get rid of all the explicit references to
> alloca.o, right?
> zw
From the config dir? No, my point (which perhaps I wasn't clear
about) is that we can't do this without extra work. I'm willing to do
this work _eventually_ but not in the original patch since I want to
keep it simple for whoever reviews it. I cleaned up obstack.o and
vfprintf.o just to sanity check whether the patch actually provides
the gcc dir "build" programs with what they need.
Regarding alloca.o, to explain myself better, the reason we can't
remove explicit references to alloca.o from the config dir or even
gcc/Makefile.in, it that libiberty doesn't currently always include
alloca.o if it decides that the system can obtain alloca via a #pragma
or including alloca.h. We'd have to add the standard hackery that you
find in libiberty/alloca-conf.h into system.h or somewhere (and test
it!) to be able to nuke these references.
Another approach which Jeff has proposed is to have libiberty always
include alloca.o. This too would require some libiberty hackery to
properly set the "cray" hooks, etc, without running the standard
autoconf alloca check. (I'd probably just chop out the pieces we'd
need and stick them in aclocal.m4.)
Either way, I don't want to mix the issues of creating a "build"
libiberty with the cleanup possible after that gets done. Have
patience please, eventually cleanup will happen. :-) There's lots more
of it than gcc/Makefile.in anyway, way too much for one jumbo patch.
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions