Matthias Klose <d...@debian.org> writes: > Same in 4.4. > > libstdc++-v3/acinclude.m4: > dnl Check for clock_gettime, nanosleep and sched_yield, used in the > dnl implementation of 20.8.5 [time.clock], and 30.2.2 [thread.thread.this] > dnl in the current C++0x working draft. > dnl > dnl --enable-libstdcxx-time > dnl --enable-libstdcxx-time=yes > dnl checks for the availability of monotonic and realtime clocks, > dnl nanosleep and sched_yield in libc and libposix4 and, in case, links > dnl the latter > dnl --enable-libstdcxx-time=rt > dnl also searches (and, in case, links) librt. Note that this is > dnl not always desirable because, in glibc, for example, in turn it > dnl triggers the linking of libpthread too, which activates locking, > dnl a large overhead for single-thread programs. > dnl --enable-libstdcxx-time=no > dnl --disable-libstdcxx-time > dnl disables the checks completely > > not enabled by other distributions as well. asked upstream: > http://gcc.gnu.org/ml/libstdc++/2010-04/msg00007.html
What seems silly is that the interfaces (std::thread::yield, std::thread::sleep_for) appear to work fine if I simply do: #define _GLIBCXX_USE_SCHED_YIELD 1 #define _GLIBCXX_USE_NANOSLEEP 1 before including <thread>. The _only_ use of those macros (in the entire c++ header suite) seems to be in deciding whether to define the relevant inline method (std::thread::sleep_for, sleep_until, yield) in the std::thread class. If those inline methods are never called, then they should have zero effect (including pulling in any extra libraries etc), so it seems like defining those macros in c++config.h would similarly have zero effect if the facilities aren't actually used by the user. Maybe other (non-linux) systems have other problems, and the gcc configure script is being a little too careful because of those other systems? -Miles -- Bore, n. A person who talks when you wish him to listen. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/buotyrp9rqp....@dhlpc061.dev.necel.com
