public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Hans-Peter Nilsson <hans-peter.nilsson@axis.com>
To: rguenther@suse.de
Cc: gcc-patches@gcc.gnu.org, jakub@redhat.com
Subject: PATCH: fix breakage from "[PATCH] Fix genmatch linking"
Date: Fri, 24 Oct 2014 04:32:00 -0000	[thread overview]
Message-ID: <201410240432.s9O4W6AK006208@ignucius.se.axis.com> (raw)
In-Reply-To: <alpine.LSU.2.11.1410231046100.9891@zhemvz.fhfr.qr> (message from	Richard Biener on Thu, 23 Oct 2014 10:47:43 +0200)

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

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

  parent reply	other threads:[~2014-10-24  4:32 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-23  9:01 [PATCH] Fix genmatch linking Richard Biener
2014-10-23  9:16 ` Jakub Jelinek
2014-10-23 12:51 ` Rainer Orth
2014-10-23 13:10   ` Richard Biener
2014-10-23 14:18     ` Richard Biener
2014-10-23 14:30       ` Richard Biener
2014-10-23 14:37         ` Richard Biener
2014-10-23 14:38           ` Richard Biener
2014-10-24  7:56             ` Rainer Orth
2014-10-24  8:07               ` Richard Biener
2014-10-24  9:51                 ` Richard Biener
2014-10-24 11:04                   ` Rainer Orth
2014-10-24 11:29                     ` Richard Biener
2014-10-23 15:27           ` Jakub Jelinek
2014-10-23 21:35 ` Richard Sandiford
2014-10-24  8:00   ` Richard Biener
2014-10-24  4:32 ` Hans-Peter Nilsson [this message]
2014-10-24  5:02   ` PATCH: fix breakage from "[PATCH] Fix genmatch linking" Hans-Peter Nilsson
2014-10-24  8:03   ` Richard Biener
2014-10-24 17:04     ` Hans-Peter Nilsson
2014-10-25  8:57       ` Richard Biener
2014-10-29  0:22   ` Paolo Bonzini
2014-10-29  0:30     ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201410240432.s9O4W6AK006208@ignucius.se.axis.com \
    --to=hans-peter.nilsson@axis.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=rguenther@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).