[PATCH] top-level for libvtv: use normal (not raw_cxx) target exports

[Michael Haubenwallner]

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/