[trunk][google/gcc47]Add dependence of configure-target-libmudflap on configure-target-libstdc++-v3

[jingyu, 2013-03-12 00:12:01]

Don't know why the email body became an attachment. Sent it again.

Hi Diego,

The nightly build of gcc-4.7 based ppc64 and ppc32 crosstools have failed
since the build server upgraded to gPrecise one week ago. Log shows a
configuration failure on libmudflap.

checking for suffix of object files... /lib/cpp
configure: error: in
`/g/nightly/build/work/gcc-4.7.x-grtev3-powerpc32-8540/rpmbuild/BUILD/.../powerpc-grtev3-linux-gnu/libmudflap':
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.

There is no /lib/cpp on gprecise server, though it should not be used here.

What happened was that libmudflap configure looks for a preprocessor by
trying $CXX -E and then backing off to /lib/cpp.  $CXX -E is failing with
"unrecognized command line option ‘-funconfigured-libstdc++’", and the
/lib/cpp backstop then fails also. The -funconfigured-libstdc++ is because
configure can't find libstdc++/scripts/testsuite_flags. This is a so-far
undiagnosed race in gcc make, masked where /lib/cpp is available.   And
that's absent because in this build, for whatever reason, libstdc++ loses a
race with libmudflap.

The theory is confirmed by:
 1) if we force --job=1, build can succeed
 2) If we apply the following patch to build-gcc/Makefile, build can
succeed. After removing this dependency, build fails with the same error
again.

Is this patch ok for google/gcc-4_7?

If the same issue exists on upstream trunk, how does the patch sound to
trunk?

Thanks,
Jing


2013-03-11  Jing Yu  <jingyu@google.com>

* Makefile.in: (maybe-configure-target-libmudflap):
Add dependence on configure-target-libstdc++-v3.

Index: Makefile.in
===================================================================
--- Makefile.in (revision 196604)
+++ Makefile.in (working copy)
@@ -31879,6 +31879,9 @@ maybe-configure-target-libmudflap:
 @if gcc-bootstrap
 configure-target-libmudflap: stage_current
 @endif gcc-bootstrap
+@if target-libstdc++-v3
+configure-target-libmudflap: configure-target-libstdc++-v3
+@endif target-libstdc++-v3
 @if target-libmudflap
 maybe-configure-target-libmudflap: configure-target-libmudflap
 configure-target-libmudflap:

--
This patch is available for review at http://codereview.appspot.com/7740043


2013/3/11 Jing Yu <jingyu@google.com>

>

[jingyu, 2013-03-12 00:17:30]

Don't know why the email body became attachment. Sent it again.
The review link is https://codereview.appspot.com/7740043

Hi Diego,

The nightly build of gcc-4.7 based ppc64 and ppc32 crosstools have failed
since
the build server upgraded to gPrecise one week ago. Log shows a
configuration fa
ilure on libmudflap.

checking for suffix of object files... /lib/cpp
configure: error: in
`/g/nightly/build/work/gcc-4.7.x-grtev3-powerpc32-8540/rpmbuild/BUILD/.../powerpc-grtev3-linux-gnu/libmudflap':
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.

There is no /lib/cpp on gprecise server, though it should not be used here.

What happened was that libmudflap configure looks for a preprocessor by
trying $CXX -E and then backing off to /lib/cpp.  $CXX -E is failing with
"unrecognized command line option ‘-funconfigured-libstdc++’", and the
/lib/cpp backstop then fails also. The -funconfigured-libstdc++ is because
configure can't find libstdc++/scripts/testsuite_flags. This is a so-far
undiagnosed race in gcc make, masked where /lib/cpp is available.   And
that's absent because in this build, for whatever reason, libstdc++ loses a
race with libmudflap.

The theory is confirmed by:
 1) if we force --job=1, build can succeed
 2) If we apply the following patch to build-gcc/Makefile, build can
succeed. After removing this dependency, build fails with the same error
again.

Is this patch ok for google/gcc-4_7?

If the same issue exists on upstream trunk, how does the patch sound to
trunk?

Thanks,
Jing

2013-03-11  Jing Yu  <jingyu@google.com>

        * Makefile.in: (maybe-configure-target-libmudflap):
        Add dependence on configure-target-libstdc++-v3.

Index: Makefile.in
===================================================================
--- Makefile.in (revision 196604)
+++ Makefile.in (working copy)
@@ -31879,6 +31879,9 @@ maybe-configure-target-libmudflap:
 @if gcc-bootstrap
 configure-target-libmudflap: stage_current
 @endif gcc-bootstrap
+@if target-libstdc++-v3
+configure-target-libmudflap: configure-target-libstdc++-v3
+@endif target-libstdc++-v3
 @if target-libmudflap
 maybe-configure-target-libmudflap: configure-target-libmudflap
 configure-target-libmudflap:


2013/3/11 Jing Yu <jingyu@google.com>

>

[jingyu, 2013-03-12 00:21:15]

Don't know why the email body became attachment. Sent it again.
The review link is https://codereview.appspot.com/7740043

Hi Diego,

The nightly build of gcc-4.7 based ppc64 and ppc32 crosstools have failed since
the build server upgraded to gPrecise one week ago. Log shows a configuration
fa
ilure on libmudflap.

checking for suffix of object files... /lib/cpp
configure: error: in
`/g/nightly/build/work/gcc-4.7.x-grtev3-powerpc32-8540/rpmbuild/BUILD/.../powerpc-grtev3-linux-gnu/libmudflap':
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.

There is no /lib/cpp on gprecise server, though it should not be used here.

What happened was that libmudflap configure looks for a preprocessor
by trying $CXX -E and then backing off to /lib/cpp.  $CXX -E is
failing with "unrecognized command line option
‘-funconfigured-libstdc++’", and the /lib/cpp backstop then fails
also. The -funconfigured-libstdc++ is because configure can't find
libstdc++/scripts/testsuite_flags. This is a so-far undiagnosed race
in gcc make, masked where /lib/cpp is available.   And that's absent
because in this build, for whatever reason, libstdc++ loses a race
with libmudflap.

The theory is confirmed by:
 1) if we force --job=1, build can succeed
 2) If we apply the following patch to build-gcc/Makefile, build can
succeed. After removing this dependency, build fails with the same
error again.

Is this patch ok for google/gcc-4_7?

If the same issue exists on upstream trunk, how does the patch sound to trunk?

Thanks,
Jing

2013-03-11  Jing Yu  <jingyu@google.com>

        * Makefile.in: (maybe-configure-target-libmudflap):
        Add dependence on configure-target-libstdc++-v3.

Index: Makefile.in
===================================================================
--- Makefile.in (revision 196604)
+++ Makefile.in (working copy)
@@ -31879,6 +31879,9 @@ maybe-configure-target-libmudflap:
 @if gcc-bootstrap
 configure-target-libmudflap: stage_current
 @endif gcc-bootstrap
+@if target-libstdc++-v3
+configure-target-libmudflap: configure-target-libstdc++-v3
+@endif target-libstdc++-v3
 @if target-libmudflap
 maybe-configure-target-libmudflap: configure-target-libmudflap
 configure-target-libmudflap:

[jingyu, 2013-03-12 17:24:33]

I made a mistake in my previous patch. I did not notice that
Makefile.in was a generated file. Update the patch.

2013-03-12  Jing Yu  <jingyu@google.com>

   * Makefile.def (Target modules dependencies): Add new dependency.
   * Makefile.in: Re-generate.


Index: Makefile.in
===================================================================
--- Makefile.in (revision 196604)
+++ Makefile.in (working copy)
@@ -44446,6 +44446,7 @@ all-target-libjava: maybe-all-target-boehm-gc
 all-target-libjava: maybe-all-target-libffi
 configure-target-libobjc: maybe-configure-target-boehm-gc
 all-target-libobjc: maybe-all-target-boehm-gc
+configure-target-libmudflap: maybe-configure-target-libstdc++-v3
 configure-target-libstdc++-v3: maybe-configure-target-libgomp

 configure-stage1-target-libstdc++-v3: maybe-configure-stage1-target-libgomp
Index: Makefile.def
===================================================================
--- Makefile.def (revision 196604)
+++ Makefile.def (working copy)
@@ -504,6 +504,7 @@ dependencies = { module=all-target-libjava; on=all
 dependencies = { module=all-target-libjava; on=all-target-libffi; };
 dependencies = { module=configure-target-libobjc;
on=configure-target-boehm-gc; };
 dependencies = { module=all-target-libobjc; on=all-target-boehm-gc; };
+dependencies = { module=configure-target-libmudflap;
on=configure-target-libstdc++-v3; };
 dependencies = { module=configure-target-libstdc++-v3;
on=configure-target-libgomp; };
 // parallel_list.o and parallel_settings.o depend on omp.h, which is
 // generated by the libgomp configure.  Unfortunately, due to the use of

On Mon, Mar 11, 2013 at 5:21 PM, Jing Yu <jingyu@google.com> wrote:
> Don't know why the email body became attachment. Sent it again.
> The review link is https://codereview.appspot.com/7740043
>
> Hi Diego,
>
> The nightly build of gcc-4.7 based ppc64 and ppc32 crosstools have failed
since
> the build server upgraded to gPrecise one week ago. Log shows a configuration
fa
> ilure on libmudflap.
>
> checking for suffix of object files... /lib/cpp
> configure: error: in
>
`/g/nightly/build/work/gcc-4.7.x-grtev3-powerpc32-8540/rpmbuild/BUILD/.../powerpc-grtev3-linux-gnu/libmudflap':
> configure: error: C++ preprocessor "/lib/cpp" fails sanity check
> See `config.log' for more details.
>
> There is no /lib/cpp on gprecise server, though it should not be used here.
>
> What happened was that libmudflap configure looks for a preprocessor
> by trying $CXX -E and then backing off to /lib/cpp.  $CXX -E is
> failing with "unrecognized command line option
> ‘-funconfigured-libstdc++’", and the /lib/cpp backstop then fails
> also. The -funconfigured-libstdc++ is because configure can't find
> libstdc++/scripts/testsuite_flags. This is a so-far undiagnosed race
> in gcc make, masked where /lib/cpp is available.   And that's absent
> because in this build, for whatever reason, libstdc++ loses a race
> with libmudflap.
>
> The theory is confirmed by:
>  1) if we force --job=1, build can succeed
>  2) If we apply the following patch to build-gcc/Makefile, build can
> succeed. After removing this dependency, build fails with the same
> error again.
>
> Is this patch ok for google/gcc-4_7?
>
> If the same issue exists on upstream trunk, how does the patch sound to
trunk?
>
> Thanks,
> Jing
>
> 2013-03-11  Jing Yu  <jingyu@google.com>
>
>         * Makefile.in: (maybe-configure-target-libmudflap):
>         Add dependence on configure-target-libstdc++-v3.
>
> Index: Makefile.in
> ===================================================================
> --- Makefile.in (revision 196604)
> +++ Makefile.in (working copy)
> @@ -31879,6 +31879,9 @@ maybe-configure-target-libmudflap:
>  @if gcc-bootstrap
>  configure-target-libmudflap: stage_current
>  @endif gcc-bootstrap
> +@if target-libstdc++-v3
> +configure-target-libmudflap: configure-target-libstdc++-v3
> +@endif target-libstdc++-v3
>  @if target-libmudflap
>  maybe-configure-target-libmudflap: configure-target-libmudflap
>  configure-target-libmudflap:

[Diego Novillo, 2013-03-12 17:28:35]

On 2013-03-12 13:24 , Jing Yu wrote:
> I made a mistake in my previous patch. I did not notice that
> Makefile.in was a generated file. Update the patch.
>
> 2013-03-12  Jing Yu  <jingyu@google.com>
>
>     * Makefile.def (Target modules dependencies): Add new dependency.
>     * Makefile.in: Re-generate.
>
>
> Index: Makefile.in
> ===================================================================
> --- Makefile.in (revision 196604)
> +++ Makefile.in (working copy)
> @@ -44446,6 +44446,7 @@ all-target-libjava: maybe-all-target-boehm-gc
>   all-target-libjava: maybe-all-target-libffi
>   configure-target-libobjc: maybe-configure-target-boehm-gc
>   all-target-libobjc: maybe-all-target-boehm-gc
> +configure-target-libmudflap: maybe-configure-target-libstdc++-v3
>   configure-target-libstdc++-v3: maybe-configure-target-libgomp
>
>   configure-stage1-target-libstdc++-v3: maybe-configure-stage1-target-libgomp
> Index: Makefile.def
> ===================================================================
> --- Makefile.def (revision 196604)
> +++ Makefile.def (working copy)
> @@ -504,6 +504,7 @@ dependencies = { module=all-target-libjava; on=all
>   dependencies = { module=all-target-libjava; on=all-target-libffi; };
>   dependencies = { module=configure-target-libobjc;
> on=configure-target-boehm-gc; };
>   dependencies = { module=all-target-libobjc; on=all-target-boehm-gc; };
> +dependencies = { module=configure-target-libmudflap;
> on=configure-target-libstdc++-v3; };
>   dependencies = { module=configure-target-libstdc++-v3;
> on=configure-target-libgomp; };
>   // parallel_list.o and parallel_settings.o depend on omp.h, which is
>   // generated by the libgomp configure.  Unfortunately, due to the use of
>
> On Mon, Mar 11, 2013 at 5:21 PM, Jing Yu <jingyu@google.com> wrote:
>> Don't know why the email body became attachment. Sent it again.
>> The review link is https://codereview.appspot.com/7740043
>>
>> Hi Diego,
>>
>> The nightly build of gcc-4.7 based ppc64 and ppc32 crosstools have failed
since
>> the build server upgraded to gPrecise one week ago. Log shows a configuration
fa
>> ilure on libmudflap.
>>
>> checking for suffix of object files... /lib/cpp
>> configure: error: in
>>
`/g/nightly/build/work/gcc-4.7.x-grtev3-powerpc32-8540/rpmbuild/BUILD/.../powerpc-grtev3-linux-gnu/libmudflap':
>> configure: error: C++ preprocessor "/lib/cpp" fails sanity check
>> See `config.log' for more details.
>>
>> There is no /lib/cpp on gprecise server, though it should not be used here.
>>
>> What happened was that libmudflap configure looks for a preprocessor
>> by trying $CXX -E and then backing off to /lib/cpp.  $CXX -E is
>> failing with "unrecognized command line option
>> ‘-funconfigured-libstdc++’", and the /lib/cpp backstop then fails
>> also. The -funconfigured-libstdc++ is because configure can't find
>> libstdc++/scripts/testsuite_flags. This is a so-far undiagnosed race
>> in gcc make, masked where /lib/cpp is available.   And that's absent
>> because in this build, for whatever reason, libstdc++ loses a race
>> with libmudflap.
>>
>> The theory is confirmed by:
>>   1) if we force --job=1, build can succeed
>>   2) If we apply the following patch to build-gcc/Makefile, build can
>> succeed. After removing this dependency, build fails with the same
>> error again.
>>
>> Is this patch ok for google/gcc-4_7?
>>
>> If the same issue exists on upstream trunk, how does the patch sound to
trunk?
>>
>> Thanks,
>> Jing
>>
>> 2013-03-11  Jing Yu  <jingyu@google.com>
>>
>>          * Makefile.in: (maybe-configure-target-libmudflap):
>>          Add dependence on configure-target-libstdc++-v3.

OK for google/gcc-4_7.  It's fine for trunk as well, but it may need to 
wait until trunk opens up again.


Diego.

>>
>> Index: Makefile.in
>> ===================================================================
>> --- Makefile.in (revision 196604)
>> +++ Makefile.in (working copy)
>> @@ -31879,6 +31879,9 @@ maybe-configure-target-libmudflap:
>>   @if gcc-bootstrap
>>   configure-target-libmudflap: stage_current
>>   @endif gcc-bootstrap
>> +@if target-libstdc++-v3
>> +configure-target-libmudflap: configure-target-libstdc++-v3
>> +@endif target-libstdc++-v3
>>   @if target-libmudflap
>>   maybe-configure-target-libmudflap: configure-target-libmudflap
>>   configure-target-libmudflap:

[jingyu, 2013-04-04 17:47:52]

I found that google/gcc-4_8 has the same problem. OK for google/gcc-4_8?

Thanks,
Jing


On Tue, Mar 12, 2013 at 10:28 AM, Diego Novillo <dnovillo@google.com> wrote:

> On 2013-03-12 13:24 , Jing Yu wrote:
>
>> I made a mistake in my previous patch. I did not notice that
>> Makefile.in was a generated file. Update the patch.
>>
>> 2013-03-12  Jing Yu  <jingyu@google.com>
>>
>>     * Makefile.def (Target modules dependencies): Add new dependency.
>>     * Makefile.in: Re-generate.
>>
>>
>> Index: Makefile.in
>> ==============================**==============================**=======
>> --- Makefile.in (revision 196604)
>> +++ Makefile.in (working copy)
>> @@ -44446,6 +44446,7 @@ all-target-libjava: maybe-all-target-boehm-gc
>>   all-target-libjava: maybe-all-target-libffi
>>   configure-target-libobjc: maybe-configure-target-boehm-**gc
>>   all-target-libobjc: maybe-all-target-boehm-gc
>> +configure-target-libmudflap: maybe-configure-target-**libstdc++-v3
>>   configure-target-libstdc++-v3: maybe-configure-target-libgomp
>>
>>   configure-stage1-target-**libstdc++-v3: maybe-configure-stage1-target-*
>> *libgomp
>> Index: Makefile.def
>> ==============================**==============================**=======
>> --- Makefile.def (revision 196604)
>> +++ Makefile.def (working copy)
>> @@ -504,6 +504,7 @@ dependencies = { module=all-target-libjava; on=all
>>   dependencies = { module=all-target-libjava; on=all-target-libffi; };
>>   dependencies = { module=configure-target-**libobjc;
>> on=configure-target-boehm-gc; };
>>   dependencies = { module=all-target-libobjc; on=all-target-boehm-gc; };
>> +dependencies = { module=configure-target-**libmudflap;
>> on=configure-target-libstdc++-**v3; };
>>   dependencies = { module=configure-target-**libstdc++-v3;
>> on=configure-target-libgomp; };
>>   // parallel_list.o and parallel_settings.o depend on omp.h, which is
>>   // generated by the libgomp configure.  Unfortunately, due to the use of
>>
>> On Mon, Mar 11, 2013 at 5:21 PM, Jing Yu <jingyu@google.com> wrote:
>>
>>> Don't know why the email body became attachment. Sent it again.
>>> The review link is
https://codereview.appspot.**com/7740043<https://codereview.appspot.com/7740043>
>>>
>>> Hi Diego,
>>>
>>> The nightly build of gcc-4.7 based ppc64 and ppc32 crosstools have
>>> failed since
>>> the build server upgraded to gPrecise one week ago. Log shows a
>>> configuration fa
>>> ilure on libmudflap.
>>>
>>> checking for suffix of object files... /lib/cpp
>>> configure: error: in
>>> `/g/nightly/build/work/gcc-4.**7.x-grtev3-powerpc32-8540/**
>>> rpmbuild/BUILD/.../powerpc-**grtev3-linux-gnu/libmudflap':
>>> configure: error: C++ preprocessor "/lib/cpp" fails sanity check
>>> See `config.log' for more details.
>>>
>>> There is no /lib/cpp on gprecise server, though it should not be used
>>> here.
>>>
>>> What happened was that libmudflap configure looks for a preprocessor
>>> by trying $CXX -E and then backing off to /lib/cpp.  $CXX -E is
>>> failing with "unrecognized command line option
>>> ‘-funconfigured-libstdc++’", and the /lib/cpp backstop then fails
>>> also. The -funconfigured-libstdc++ is because configure can't find
>>> libstdc++/scripts/testsuite_**flags. This is a so-far undiagnosed race
>>> in gcc make, masked where /lib/cpp is available.   And that's absent
>>> because in this build, for whatever reason, libstdc++ loses a race
>>> with libmudflap.
>>>
>>> The theory is confirmed by:
>>>   1) if we force --job=1, build can succeed
>>>   2) If we apply the following patch to build-gcc/Makefile, build can
>>> succeed. After removing this dependency, build fails with the same
>>> error again.
>>>
>>> Is this patch ok for google/gcc-4_7?
>>>
>>> If the same issue exists on upstream trunk, how does the patch sound to
>>> trunk?
>>>
>>> Thanks,
>>> Jing
>>>
>>> 2013-03-11  Jing Yu  <jingyu@google.com>
>>>
>>>          * Makefile.in: (maybe-configure-target-**libmudflap):
>>>          Add dependence on configure-target-libstdc++-v3.
>>>
>>
> OK for google/gcc-4_7.  It's fine for trunk as well, but it may need to
> wait until trunk opens up again.
>
>
> Diego.
>
>
>
>>> Index: Makefile.in
>>> ==============================**==============================**=======
>>> --- Makefile.in (revision 196604)
>>> +++ Makefile.in (working copy)
>>> @@ -31879,6 +31879,9 @@ maybe-configure-target-**libmudflap:
>>>   @if gcc-bootstrap
>>>   configure-target-libmudflap: stage_current
>>>   @endif gcc-bootstrap
>>> +@if target-libstdc++-v3
>>> +configure-target-libmudflap: configure-target-libstdc++-v3
>>> +@endif target-libstdc++-v3
>>>   @if target-libmudflap
>>>   maybe-configure-target-**libmudflap: configure-target-libmudflap
>>>   configure-target-libmudflap:
>>>
>>
>

[Diego Novillo, 2013-04-04 17:52:56]

On 2013-04-04 13:47 , Jing Yu wrote:
> I found that google/gcc-4_8 has the same problem. OK for google/gcc-4_8?

Yes.  Thanks.


Diego.