This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Detect obstacks in libc
- To: law at cygnus dot com, zack at wolery dot cumb dot org
- Subject: Re: Detect obstacks in libc
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Thu, 6 Jul 2000 14:26:25 -0400 (EDT)
- Cc: gcc-patches at gcc dot gnu dot org
> From: Zack Weinberg <zack@wolery.cumb.org>
>
> On Wed, Jul 05, 2000 at 06:54:27PM -0600, Jeffrey A Law wrote:
> > d
> > In message <20000704223926.F274@wolery.cumb.org>you write:
> > > obstack.c already detects whether obstacks are in the system C
> > > library, but it's worthwhile to have configure notice too, because
> > > then we don't bother building the "host" version of the object file
> > > for native builds.
> > >
> > > The aclocal.m4 test is a clone of the test in obstack.c. It might
> > > conceivably be worthwhile to use AC_FUNC(_obstack_begin) instead, if
> > > there's a libc out there that has obstacks but not <gnu-versions.h>
> > > (I doubt it).
> > >
> > > No makefile fragment that I can find overrides OBSTACK.
> > On what do we gain by using obstack in the system C library?
>
> As I said, with this change we don't bother building the "host"
> version of obstack.o in a native build.
During a private discussion with Mark and Jeff, Mark approved one of
my "host/build" libiberty patches. I just haven't got around to
installing it yet, but I'll give it more priority as soon as I can.
So if all you're trying to do is avoid building "host" obstack, it may
be moot shortly.
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions