This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] top-level for libvtv: use normal (not raw_cxx) target exports
- From: Michael Haubenwallner <michael dot haubenwallner at ssi-schaefer dot com>
- To: Jeff Law <law at redhat dot com>, Paolo Bonzini <bonzini at gnu dot org>, DJ Delorie <dj at redhat dot com>, Nathanael Nerode <neroden at gcc dot gnu dot org>, Alexandre Oliva <aoliva at redhat dot com>, Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Caroline Tice <cmtice at google dot com>, Jonathan Wakely <jwakely at redhat dot com>
- Date: Mon, 29 Jun 2015 18:57:20 +0200
- Subject: Re: [PATCH] top-level for libvtv: use normal (not raw_cxx) target exports
- Authentication-results: sourceware.org; auth=none
- References: <5576F69F dot 3090205 at ssi-schaefer dot com> <558C5338 dot 9040906 at redhat dot com>
On 06/25/2015 09:15 PM, Jeff Law wrote:
> On 06/09/2015 08:22 AM, Michael Haubenwallner wrote:
>> Hi build machinery maintainers,
>>
>> since we always build the C++ compiler now, I fail to see the need to still
>> use RAW_CXX_TARGET_EXPORTS for libvtv.
> But why is vtv special here?
> Wouldn't this also apply to libstdc++-v3 which would still have raw_cxx=true after your change?
libstdc++ breaks with shell syntax errors in maintainer-mode, which more obviously
spots the "configure script recreation while running" as the breakage's origin,
where the simple enough workaround is to run 'make bootstrap' again.
This is because libstdc++-v3/configure runs 'generate-headers' (via config.status),
which is 'cd include && make', causing dependencies in 'include/Makefile' to be
evaluated, causing make to run autoconf to recreate libstdc++-v3/configure.
Actually, an unexpected libstdc++-v3/configure change is introduced by some
inconsistency in https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=223196
where acinclude.m4 contains different code than the recreated configure:
acinclude.m4-3973: case "${target_os}" in
acinclude.m4#3974: gnu* | linux* | solaris*)
acinclude.m4-3975: GCC_TRY_COMPILE_OR_LINK(
configure-79218: case "${target_os}" in
configure#79219: gnu* | linux* | kfreebsd*-gnu | knetbsd*-gnu | solaris*)
configure-79220: if test x$gcc_no_link = xyes; then
Not sure how to handle such kind of inconsistencies though...
> It's unfortunate that David didn't document the meaning of raw_cxx...
> I've read the threads from 2004 and I'm still lost.
For vtv the breakage once resulted in the different CC/CXX values here,
but that must've been related to maintainer-mode actually, not raw_cxx.
>From my point of view, this breakage vanished as reason for the raw_cxx patch.
/haubi/