Bootstrapping glibc vs. dependency on system headers

[Thomas Schwinge <thomas at codesourcery dot com>]

Hi!

Also known as: ÂI found another oneÂ.

As we already know, glibc's configure script is in a difficult position
in that it uses "standard Autoconf", but its tests shall not depend on
any functionality (for example, system headers) that is to be supplied by
the glibc we're about to build.  In reality, often, this is not much of a
concern: most systems already have a C library installed and its header
files are sufficient for resolving the configure tests to the
correct/expected results.  But for the bootstrapping case (and for
correctness' sake!), it is desirable to avoid any such cases.  We have
fixed several such issues in the past; now I have stumbled over another
one.  Very early when configuring glibc for bootstrapping an ARM
toolchain, I get:

    [...]
    checking host system type... arm-none-linux-gnueabi
    checking for arm-none-linux-gnueabi-gcc... [...]/bin/arm-none-linux-gnueabi-gcc [some flags]
    [...]
    checking how to run the C preprocessor... /lib/cpp
    [...]

In the following checks, the C preprocessor is used for deciding whether
this is a hard-float or soft-float toolchain, based upon __ARM_PCS_VFP
being defined or not.  Using the build system's native /lib/cpp for this
test obviously can't yield the desired result.

Issue 1: Can the fallback /lib/cpp for the C preprocessor ever be useful
in the cross-compilation case?  Instead of using that, in this case I'd
rather have configure stop with an error message.

What Âchecking how to run the C preprocessor does first is testing
whether Â$CC -EÂ is suitable.  For the curious: this failed in my case as
the sysroot's header files already did contain support for soft-float,
but they were not yet prepared to handle the hard-float case
(__ARM_PCS_VFP being defined), and so <gnu/stubs.h> tried to Â#include
<gnu/stubs-hard.h>Â, which has not yet been generated and installed into
the sysroot.  In turn, that file is included by means of limits.h, which
is used in the Âchecking how to run the C preprocessor Autoconf test:

[autoconf]/lib/autoconf/c.m4:

    # _AC_PROG_PREPROC_WORKS_IFELSE(IF-WORKS, IF-NOT)
    # -----------------------------------------------
    # Check if $ac_cpp is a working preprocessor that can flag absent
    # includes either by the exit status or by warnings.
    # This macro is for all languages, not only C.
    AC_DEFUN([_AC_PROG_PREPROC_WORKS_IFELSE],
    [ac_preproc_ok=false
    for ac_[]_AC_LANG_ABBREV[]_preproc_warn_flag in '' yes
    do
      # Use a header file that comes with gcc, so configuring glibc
      # with a fresh cross-compiler works.
      # On the NeXT, cc -E runs the code through the compiler's parser,
      # not just through cpp. "Syntax error" is here to catch this case.
      _AC_PREPROC_IFELSE([AC_LANG_SOURCE([[@%:@include <limits.h>
                         Syntax error]])],
                         [],
                         [# Broken: fails on valid input.
    continue])
    [...]

(The test in glibc's configure file is slightly older (missing Autoconf
commit f52459d158bcf5edd4ca75a453bb012efd0f4d90), but in essence is the
same.)  So despite Â[using] a header file that comes with gccÂ, limits.h
will actually include additional files down the road that are not GCC's
but glibc's.  (Run: Âecho '#include <limits.h>' | gcc -E -x c -Â to see.)

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

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


GrÃÃe,
 Thomas

Attachment: pgp00000.pgp
Description: PGP signature