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/