This is the mail archive of the
mailing list for the glibc project.
Re: Bootstrapping glibc vs. dependency on system headers
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: <bug-autoconf at gnu dot org>, <libc-alpha at sourceware dot org>, <gcc at gcc dot gnu dot org>
- Date: Thu, 17 Jan 2013 17:18:41 +0000
- Subject: Re: Bootstrapping glibc vs. dependency on system headers
- References: <email@example.com>
On Thu, 17 Jan 2013, Thomas Schwinge wrote:
> Issue 2: Though it will of course never be completely fail-safe,
> candidate header files I identified to remedy this issue and to be used
> in _AC_PROG_PREPROC_WORKS_IFELSE instead of limits.h are: float.h,
> stdarg.h, stddef.h (though the latter might include additional files in
> *BSD environments, which may be supported by glibc, so let's better not
> use that one). Is using one of float.h and stdarg.h correct in this
> situation, and do you want me to write an Autoconf patch to change that?
> By manually modifying configure, I tested using stdarg.h, and that looks
limits.h is unsafe for such bootstrapping, as you found, because of how
the GCC and glibc copies install each other.
Really, for glibc bootstrapping I don't think you want to include any
headers there. If $CPP is defined and nonempty, use that, otherwise use
$CC -E; no testing for a "working" preprocessor is needed; we require GCC
4.3 or later for building glibc.
> Issue 3: Assuming fixing Autoconf is the way to go, what do we do in
> glibc until we upgrade to the respective future version of Autoconf?
> Supply our own copy of _AC_PROG_PREPROC_WORKS_IFELSE (or AC_PROG_CPP)?
Yes. There's already code in configure.in to do something special with
Joseph S. Myers