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

Jonathan Wakely jwakely.gcc@gmail.com
Wed Apr 28 08:17:00 GMT 2010


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.



More information about the Libstdc++ mailing list