Bug#575997: libstdc++6-4.5-dev: c++config.h doesn't seem to match reality
Matthias Klose <firstname.lastname@example.org> writes:
> Same in 4.4.
> 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 --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:
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
Bore, n. A person who talks when you wish him to listen.