Re: [patch] Fix --enable-libstdcxx-time documentation, show configure result

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 28 April 2010 04:56, Miles Bader wrote:
> Miles Bader <miles@gnu.org> writes:
>> The comment in configure.ac says:
>>
>> ? ?# For clock_gettime, nanosleep and sched_yield support.
>> ? ?# NB: The default is [no], because otherwise it requires linking.
>> ? ?GLIBCXX_ENABLE_LIBSTDCXX_TIME([no])
> ...
>> The only effect of __GLIBCXX_USE_SCHED_YIELD and _GLIBCXX_USE_NANOSLEEP
>> in the libstc++ headers is to define the relevant inline methods
>> (std::thread::sleep_for, sleep_until, yield) in the std::thread class.
> ...
>> Given that the std::thread interface is incomplete without these
>> enabled, and enabling them seems to have no overhead or effect unless
>> they're actually used (and the overhead is obviously desired in that
>> case!), wouldn't it be better to enable them by default?
>
> Hmmm, nobody has any insight into this?
>
> Is there a reason I shouldn't file a bug about it?

I was actually just going to reply today.

I've been wondering about it myself.  Using
--enable-libstdcxx-time=yes will try to link a program to determine if
libposix4 is needed.  I don't think configure can link in the case of
a cross compiler, so that would always fail. Also, on platforms where
libposix4 is needed it would add an extra dependency to libstdc++.so,
which not all users will want for an experimental c++0x mode.

For native linux builds I think you are right and it has no downside,
so distros could enable it by default.

That still doesn't give a fully-conforming implementation though,, for
that a monotonic clock is needed, which needs librt
(enable-llibstdx-time=rt) and that definitely hass a downside as it
makes libstdc++ depend on libpthread which turns on locking in libc.