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: Check for ucontext.h and sys/ucontext.h


> 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>


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