[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bootstrapping glibc vs. dependency on system headers

From: Thomas Schwinge
Subject: Bootstrapping glibc vs. dependency on system headers
Date: Thu, 17 Jan 2013 18:09:33 +0100
User-agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-pc-linux-gnu)


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:


    # -----------------------------------------------
    # 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.
    for ac_[]_AC_LANG_ABBREV[]_preproc_warn_flag in '' yes
      # 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(address@hidden:@include <limits.h>
                         Syntax error]])],
                         [# Broken: fails on valid input.

(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

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


Attachment: pgpA96YMDHfBA.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]