scripts/libc: do not build add-ons by default

Currently, no --enable-add-ons option is passed to libc configure when
"$(do_libc_add_ons_list ,)" is empty, which makes configure automatically search
for present add-ons. In that case, all present add-ons are built, although
no add-on was selected by the user in the config. Moreover, this can make the
configure fail if some non-standard add-ons like eglibc-localedef are present.

This behavior also leads to an inconsistency from a user point of view between
the following cases:
- LIBC_ADDONS_LIST="", LIBC_GLIBC_USE_PORTS=n and THREADS="none" in the config,
which makes "$(do_libc_add_ons_list ,)" return "", so all present add-ons
are built.
- LIBC_ADDONS_LIST="", LIBC_GLIBC_USE_PORTS=n and THREADS!="none" in the
config, which makes "$(do_libc_add_ons_list ,)" return the add-on supporting
the chosen threading implementation, e.g. "nptl", so only this add-on is
built.

This patch disables the building of all add-ons in that case.

It is still possible to build all present add-ons by adding --enable-add-ons to
LIBC_GLIBC_EXTRA_CONFIG_ARRAY.

Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>

--- ppl-0.10.2/configure.orig	2010-08-04 21:48:19.000000000 -0400

+++ ppl-0.10.2/configure	2010-08-04 21:50:04.000000000 -0400

@@ -16443,6 +16443,10 @@

 #GMP version 4.1.3 or higher is required

 #endif

+#ifndef BITS_PER_MP_LIMB

+#define BITS_PER_MP_LIMB GMP_LIMB_BITS

+#endif

+

 int

 main() {

   std::string header_version;

@@ -16469,11 +16473,11 @@

     return 1;

   }

-  if (sizeof(mp_limb_t)*CHAR_BIT != GMP_LIMB_BITS

-      || GMP_LIMB_BITS != mp_bits_per_limb) {

+  if (sizeof(mp_limb_t)*CHAR_BIT != BITS_PER_MP_LIMB

+      || BITS_PER_MP_LIMB != mp_bits_per_limb) {

     std::cerr

       << "GMP header (gmp.h) and library (ligmp.*) bits-per-limb mismatch:\n"

-      << "header gives " << __GMP_BITS_PER_MP_LIMB << ";\n"

+      << "header gives " << BITS_PER_MP_LIMB << ";\n"

       << "library gives " << mp_bits_per_limb << ".\n"

       << "This probably means you are on a bi-arch system and\n"

       << "you are compiling with the wrong header or linking with\n"