> From: Richard Biener <rguent...@suse.de>
> Date: Thu, 23 Oct 2014 10:47:43 +0200

> This adds a libcpp host module without NLS and ICONV support
> and properly links genmatch against the build libcpp instead of
> the host one.
> 
> Bootstrap running on x86_64-unknown-linux-gnu (stage1 all-gcc
> finished fine).
> 
> Ok for trunk?
> 
> Thanks,
> Richard.
> 
> 2014-10-23  Richard Biener  <rguent...@suse.de>
> 
>       * Makefile.def: Add libcpp build module and dependencies.
>       * configure.ac: Add libcpp build module.
>       * Makefile.in: Regenerate.
>       * configure: Likewise.

You only exposed a dormant issue, but ever since this commit
(nominally, some commit in "(216573:216588]" but I only see this
one matching) I see, for cross-builds (to cris-elf):

make[2]: Entering directory 
`/tmp/hpautotest-gcc1/cris-elf/gccobj/build-x86_64-unknown-linux-gnu/libcpp'
g++  -I/tmp/hpautotest-gcc1/gcc/libcpp -I. 
-I/tmp/hpautotest-gcc1/gcc/libcpp/../include 
-I/tmp/hpautotest-gcc1/gcc/libcpp/include  -g -O2 -W -Wall -Wwrite-strings 
-Wmissing-format-attribute -pedantic -Wno-long-long  -fno-exceptions -fno-rtti 
-I/tmp/hpautotest-gcc1/gcc/libcpp -I. 
-I/tmp/hpautotest-gcc1/gcc/libcpp/../include 
-I/tmp/hpautotest-gcc1/gcc/libcpp/include   -c -o charset.o -MT charset.o -MMD 
-MP -MF .deps/charset.Tpo /tmp/hpautotest-gcc1/gcc/libcpp/charset.c
In file included from /tmp/hpautotest-gcc1/gcc/libcpp/system.h:370,
                 from /tmp/hpautotest-gcc1/gcc/libcpp/charset.c:21:
/tmp/hpautotest-gcc1/gcc/libcpp/../include/libiberty.h:113: error: new 
declaration 'char* basename(const char*)'
/usr/include/string.h:601: error: ambiguates old declaration 'const char* 
basename(const char*)'
make[2]: *** [charset.o] Error 1
make[2]: Leaving directory 
`/tmp/hpautotest-gcc1/cris-elf/gccobj/build-x86_64-unknown-linux-gnu/libcpp'
make[1]: *** [all-build-libcpp] Error 2
make[1]: Leaving directory `/tmp/hpautotest-gcc1/cris-elf/gccobj'
make: *** [all] Error 2

Above that, we have:
checking whether basename is declared... (cached) no

and above that, we have:
make[2]: Leaving directory 
`/tmp/hpautotest-gcc1/cris-elf/gccobj/build-x86_64-unknown-linux-gnu/fixincludes'
mkdir -p -- build-x86_64-unknown-linux-gnu/libcpp
Configuring in build-x86_64-unknown-linux-gnu/libcpp
configure: loading cache ../config.cache

which is apparently set due to (above that, first non-cached):
mkdir -p -- build-x86_64-unknown-linux-gnu/libiberty
Configuring in build-x86_64-unknown-linux-gnu/libiberty
configure: creating cache ../config.cache
...
checking whether basename is declared... no

Your commit introduces build-subdirectories for cross-builds.
Build-subdirs share a config.cache (in build-<host>/config.cache),
with subdirs in build-<host> being fixincludes, libcpp and
libiberty.

But, libiberty and fixincludes are configure-tested and compiled
using gcc, while libcpp is compiled with g++, which causes a
different set of declarations to be exposed, so the shared
config.cache is invalid and its use is bogus.  Not sure how this
works for native builds.

The libcpp configure checks are actually run with gcc which is
bogus by itself, but apparently working.  I guess the C vs. C++
declaration etc. differences for libcpp are mostly hidden by
using _GNU_SOURCE (through AC_USE_SYSTEM_EXTENSIONS), and I'm a
bit surprised that's not used for libiberty and fixincludes.
Still, a red herring.  Aligning those options *may* cause the
build to succeed, but I think that'd be too much of sweeping the
issue under the carpet.

It seems "more correct" to just disable the config.cache sharing
between the differently-configured build-subdirectories, as is
already is done for host-libraries and target-libraries, even if
that may slow down the builds.  (Erroring out is infinitely
slower. :)  Still, I don't understand exactly how your patch
introduces build-subdirectories where there were none before.
Maybe that "+all-gcc: maybe-all-build-libcpp" was wrong and
should be different?

Anyway, with this, a cris-elf cross build passes the point of
failure; compilers and libraries built, progressing into
testing.

Ok to commit?

toplev:
        * configure.ac (build_configargs): Don't share
        config.cache between build subdirs.

Index: configure.ac
===================================================================
--- configure.ac        (revision 216610)
+++ configure.ac        (working copy)
@@ -2922,8 +2922,10 @@ AC_ARG_VAR([target_configargs],
 
 # For the build-side libraries, we just need to pretend we're native,
 # and not use the same cache file.  Multilibs are neither needed nor
-# desired.
-build_configargs="$build_configargs --cache-file=../config.cache ${baseargs}"
+# desired.  We can't even use the same cache file for all build-side
+# libraries, as they're compiled differently; some with C, some with
+# C++ or with different feature-enabling options.
+build_configargs="$build_configargs --cache-file=./config.cache ${baseargs}"
 
 # For host modules, accept cache file option, or specification as blank.
 case "${cache_file}" in
Index: configure
===================================================================
--- configure   (revision 216610)
+++ configure   (working copy)
@@ -7386,8 +7386,10 @@ tbaseargs="$tbaseargs --disable-option-c
 
 # For the build-side libraries, we just need to pretend we're native,
 # and not use the same cache file.  Multilibs are neither needed nor
-# desired.
-build_configargs="$build_configargs --cache-file=../config.cache ${baseargs}"
+# desired.  We can't even use the same cache file for all build-side
+# libraries, as they're compiled differently; some with C, some with
+# C++ or with different feature-enabling options.
+build_configargs="$build_configargs --cache-file=./config.cache ${baseargs}"
 
 # For host modules, accept cache file option, or specification as blank.
 case "${cache_file}" in

brgds, H-P

Reply via email to