This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Check for ucontext.h and sys/ucontext.h
- To: jsm28 at cam dot ac dot uk
- Subject: Re: Check for ucontext.h and sys/ucontext.h
- From: Geoff Keating <geoffk at geoffk dot org>
- Date: Sun, 4 Nov 2001 12:12:10 -0800
- CC: rodrigc at mediaone dot net, gcc-patches at gcc dot gnu dot org, rth at redhat dot com
- References: <Pine.LNX.4.33.0111041922570.16774-100000@kern.srcf.societies.cam.ac.uk>
- Reply-to: Geoff Keating <geoffk at redhat dot com>
> Date: Sun, 4 Nov 2001 19:29:46 +0000 (GMT)
> From: "Joseph S. Myers" <jsm28@cam.ac.uk>
> X-X-Sender: <jsm28@kern.srcf.societies.cam.ac.uk>
> cc: <rodrigc@mediaone.net>, <gcc-patches@gcc.gnu.org>, <rth@redhat.com>
>
> On Sun, 4 Nov 2001, Geoff Keating wrote:
>
> > > PR 4068 mentions that he is using glibc 2.0.7, so it is
> > > not a libc1 system. It looks like ucontext.h was added
> > > in GNU libc 2.1 and higher.
> >
> > OK. In that case, we probably need to add a version number to the
> > triplet. Inside Red Hat, we use
> >
> > i686-pc-linux-gnulibc2.0
> > i686-pc-linux-gnulibc2.1
> > i686-pc-linux-gnulibc2.2
>
> Can't we work out some way to do a target-autoconf stage rather than
> multiplying target triplets? Just before building libgcc, it should be
> possible to test whether the just-built compiler can find particular
> target headers.
That would make sense. Ideally, there would even be a fallback
position for "just-built compiler doesn't seem to have any headers
available at all".
> With some more complexity, it should be possible to test
> for limited target library properties as well, before building libgcc -
> and so eliminate TARGET_MEM_FUNCTIONS by testing for the ISO C string
> functions in libc and putting them in libgcc if they aren't in libc.
One major difficulty there is that glibc requires libgcc to be built
first.
--
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>