| Message ID | 201410240432.s9O4W6AK006208@ignucius.se.axis.com |
|---|---|
| State | New |
| Headers | show |
On Fri, 24 Oct 2014, Hans-Peter Nilsson wrote: > > From: Richard Biener <rguenther@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 <rguenther@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? No, we do need a build-libcpp to build gcc/build/genmatch. Not sure how you got around without a build-libiberty as other gen* programs surely require that. > Anyway, with this, a cris-elf cross build passes the point of > failure; compilers and libraries built, progressing into > testing. > > Ok to commit? Ok. Thanks, Richard. > 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 > >
On 10/24/2014 06:32 AM, Hans-Peter Nilsson wrote: > 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. Yes, please do.
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