* [Bug libstdc++/64638] Build failure with recent futex changes in libstdc++, likely all non-futex targets
2015-01-17 4:39 [Bug libstdc++/64638] New: Build failure with recent futex changes in libstdc++, likely all non-futex targets hp at gcc dot gnu.org
@ 2015-01-17 4:40 ` hp at gcc dot gnu.org
2015-01-17 5:40 ` hp at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: hp at gcc dot gnu.org @ 2015-01-17 4:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64638
--- Comment #1 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
Forgot to say the obvious: committer in CC is singled out only because of the
context of the error message.
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug libstdc++/64638] Build failure with recent futex changes in libstdc++, likely all non-futex targets
2015-01-17 4:39 [Bug libstdc++/64638] New: Build failure with recent futex changes in libstdc++, likely all non-futex targets hp at gcc dot gnu.org
2015-01-17 4:40 ` [Bug libstdc++/64638] " hp at gcc dot gnu.org
@ 2015-01-17 5:40 ` hp at gcc dot gnu.org
2015-01-17 12:01 ` [Bug libstdc++/64638] Build failure with recent futex changes in libstdc++, likely all non-gthreads targets uweigand at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: hp at gcc dot gnu.org @ 2015-01-17 5:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64638
Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |redi at gcc dot gnu.org
--- Comment #2 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
At the risk of waving a red herring, in revision r219770, I see:
+++ libstdc++-v3/include/bits/atomic_futex.h (revision 219770)
...
+#if !defined(_GLIBCXX_HAVE_LINUX_FUTEX)
+#include <mutex>
+#include <condition_variable>
+#endif
(no guard _GLIBCXX_HAS_GTHREADS)
but in include/std/condition_variable and mutex, respectively
#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1)
...
#ifdef _GLIBCXX_HAS_GTHREADS
around the interesting bits (class mutex etc.)
and in the build log:
checking for gthreads library... no
so, is a #ifdef _GLIBCXX_HAS_GTHREADS just missing from atomic_futex.h (or some
similar missing guard)?
CC:ing reviewer.
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug libstdc++/64638] Build failure with recent futex changes in libstdc++, likely all non-gthreads targets
2015-01-17 4:39 [Bug libstdc++/64638] New: Build failure with recent futex changes in libstdc++, likely all non-futex targets hp at gcc dot gnu.org
2015-01-17 4:40 ` [Bug libstdc++/64638] " hp at gcc dot gnu.org
2015-01-17 5:40 ` hp at gcc dot gnu.org
@ 2015-01-17 12:01 ` uweigand at gcc dot gnu.org
2015-01-17 13:16 ` [Bug libstdc++/64638] [5 Regression] " redi at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: uweigand at gcc dot gnu.org @ 2015-01-17 12:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64638
Ulrich Weigand <uweigand at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |uweigand at gcc dot gnu.org
--- Comment #3 from Ulrich Weigand <uweigand at gcc dot gnu.org> ---
I see the same failure on spu-elf (another non-gthreads target).
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug libstdc++/64638] [5 Regression] Build failure with recent futex changes in libstdc++, likely all non-gthreads targets
2015-01-17 4:39 [Bug libstdc++/64638] New: Build failure with recent futex changes in libstdc++, likely all non-futex targets hp at gcc dot gnu.org
` (2 preceding siblings ...)
2015-01-17 12:01 ` [Bug libstdc++/64638] Build failure with recent futex changes in libstdc++, likely all non-gthreads targets uweigand at gcc dot gnu.org
@ 2015-01-17 13:16 ` redi at gcc dot gnu.org
2015-01-17 13:49 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2015-01-17 13:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64638
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2015-01-17
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Target Milestone|--- |5.0
Summary|Build failure with recent |[5 Regression] Build
|futex changes in libstdc++, |failure with recent futex
|likely all non-gthreads |changes in libstdc++,
|targets |likely all non-gthreads
| |targets
Ever confirmed|0 |1
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug libstdc++/64638] [5 Regression] Build failure with recent futex changes in libstdc++, likely all non-gthreads targets
2015-01-17 4:39 [Bug libstdc++/64638] New: Build failure with recent futex changes in libstdc++, likely all non-futex targets hp at gcc dot gnu.org
` (3 preceding siblings ...)
2015-01-17 13:16 ` [Bug libstdc++/64638] [5 Regression] " redi at gcc dot gnu.org
@ 2015-01-17 13:49 ` redi at gcc dot gnu.org
2015-01-17 13:50 ` redi at gcc dot gnu.org
2015-01-17 23:28 ` hp at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2015-01-17 13:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64638
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Author: redi
Date: Sat Jan 17 13:48:48 2015
New Revision: 219799
URL: https://gcc.gnu.org/viewcvs?rev=219799&root=gcc&view=rev
Log:
PR libstdc++/64638
* include/bits/atomic_futex.h: Use appropriate config macros for
availability of std::mutex, std::condition and std::chrono.
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/atomic_futex.h
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug libstdc++/64638] [5 Regression] Build failure with recent futex changes in libstdc++, likely all non-gthreads targets
2015-01-17 4:39 [Bug libstdc++/64638] New: Build failure with recent futex changes in libstdc++, likely all non-futex targets hp at gcc dot gnu.org
` (4 preceding siblings ...)
2015-01-17 13:49 ` redi at gcc dot gnu.org
@ 2015-01-17 13:50 ` redi at gcc dot gnu.org
2015-01-17 23:28 ` hp at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2015-01-17 13:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64638
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to work| |4.9.3
Version|unknown |5.0
Known to fail| |5.0
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It should be fixed now, but I'll leave this open until someone confirms the
build works again.
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug libstdc++/64638] [5 Regression] Build failure with recent futex changes in libstdc++, likely all non-gthreads targets
2015-01-17 4:39 [Bug libstdc++/64638] New: Build failure with recent futex changes in libstdc++, likely all non-futex targets hp at gcc dot gnu.org
` (5 preceding siblings ...)
2015-01-17 13:50 ` redi at gcc dot gnu.org
@ 2015-01-17 23:28 ` hp at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: hp at gcc dot gnu.org @ 2015-01-17 23:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64638
Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #6 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #5)
> It should be fixed now, but I'll leave this open until someone confirms the
> build works again.
Fixed for cris-elf, for example at r219800.
I see a conversation that other targets may have different experiences, but
I'll let them deal with that, suggesting to "take the lock" and either
re-opening and (hopefully in due time also) re-closing this PR, or a new one.
^ permalink raw reply [flat|nested] 8+ messages in thread