When trying to compile any application using the new C++11 multi-threading tools, some important functions and methods can not be used. Example: --- error: 'sleep_for' is not a member of 'std::this_thread' error: 'yield' is not a member of 'std::this_thread' --- According to the answer by Jonathan Wakely to the linked stackoverflow question, the reason is that _GLIBCXX_USE_NANOSLEEP is not defined, and that it will only be defined if the option --enable-libstdcxx-time is given to configure. Looking in my last build log for sys-devel/gcc I found the following: --- checking for clock_gettime, nanosleep and sched_yield... no --- The configure line in the log show neither an enabling or disabling of "libstdcxx-time" which seems to prove that the disabling is the default. Reproducible: Always Steps to Reproduce: 1. Compile anything with g++ using std::this_thread::sleep_for() or std::this_thread::yield() Actual Results: The new methods for laying threads to sleep are not available. Expected Results: The new methods should either be available by default (supported (almost?) anywhere anyway) or at least be tunable by a USE-flag. Again the link, I have never used the URL-field in the bug submission form and do not trust the outcome (, yet).
While updating to gcc-4.7.2 I am using the ebuild command. After "configure" I have added --enable-libstdcxx-time in temp/environment and the configure (after ebuild (...) compile) log now contains: checking for clock_gettime, nanosleep and sched_yield... yes
it'll be fixed when glibc-2.17 is released *** This bug has been marked as a duplicate of bug 411681 ***
(In reply to comment #2) > it'll be fixed when glibc-2.17 is released > > *** This bug has been marked as a duplicate of bug 411681 *** This is a gcc configuration issue and has nothing to do with glibc. Without the mentioned configure option, that necessary checks are _not_ performed. Please see my answer in bug 411681 for further reference.
(In reply to comment #3) except that it does because we are not going to enable a configuration that ends up linking in -lrt. and in order for that to not happen, you need glibc-2.17+.
(In reply to comment #4) > (In reply to comment #3) > > except that it does because we are not going to enable a configuration that > ends up linking in -lrt. and in order for that to not happen, you need > glibc-2.17+. Okay, I did not know that. What I do not understand are the following two details: 1.: librt belongs to glibc. So what is so bad with -lrt? If -lrt is no longer needed with glibc-2.17+, it means the relevant code has been moved. Where exactly is the problem with that? 2.: What is counting against a user-decided option (like a USE flag) ? I can't imagine that I am the only having to "hack" that option into gcc right now. It works now, and after adding that option the performance of a multi-threaded test program (insert 1 million elements into a simple singly linked list with 8 threads) improved from 1700ms to 200ms. Don't understand me wrong, please, I simply want to know where the problem is.
(In reply to comment #5) as i said, please read the explanation in the other bug as to why -lrt is bad glibc-2.17 has moved the required functions from -lrt to -lc which means the problems with using -lrt no longer exist and we can enable the functionality for "free". which we will unconditionally. then there's no point to a USE flag.
