Boost C++ Libraries: Ticket #7980: Build error: msvc-11.0 and BOOST_THREAD_DONT_USE_DATETIME

owner, status changed

viboes — Tue, 05 Feb 2013 21:46:47 GMT

owner changed from Anthony Williams to viboes
status new → assigned

Waiting for a fix, maybe you could try defining BOOST_THREAD_PROVIDES_GENERIC_SHARED_MUTEX_ON_WIN.

viboes — Tue, 05 Feb 2013 21:59:19 GMT

Does this patch fixes the issue?

svn diff ../../../boost/thread/win32/shared_mutex.hpp
Index: ../../../boost/thread/win32/shared_mutex.hpp
===================================================================
--- ../../../boost/thread/win32/shared_mutex.hpp	(revision 82706)
+++ ../../../boost/thread/win32/shared_mutex.hpp	(working copy)
@@ -133,7 +133,11 @@
         void lock_shared()
         {
+#if defined BOOST_THREAD_USES_DATETIME
             BOOST_VERIFY(timed_lock_shared(::boost::detail::get_system_time_sentinel()));
+#else
+            BOOST_VERIFY(try_lock_shared_until(chrono::steady_clock::now()));
+#endif
         }
 #if defined BOOST_THREAD_USES_DATETIME
@@ -379,14 +383,20 @@
         void lock()
         {
+#if defined BOOST_THREAD_USES_DATETIME
             BOOST_VERIFY(timed_lock(::boost::detail::get_system_time_sentinel()));
+#else
+            BOOST_VERIFY(try_lock_until(chrono::steady_clock::now()));
+#endif
         }
+#if defined BOOST_THREAD_USES_DATETIME
         template<typename TimeDuration>
         bool timed_lock(TimeDuration const & relative_time)
         {
             return timed_lock(get_system_time()+relative_time);
         }
+#endif
         bool try_lock()
         {
@@ -414,6 +424,7 @@
         }
+#if defined BOOST_THREAD_USES_DATETIME
         bool timed_lock(boost::system_time const& wait_until)
         {
             for(;;)
@@ -492,7 +503,7 @@
                 BOOST_ASSERT(wait_res<2);
             }
         }
-
+#endif
 #ifdef BOOST_THREAD_USES_CHRONO
         template <class Rep, class Period>
         bool try_lock_for(const chrono::duration<Rep, Period>& rel_time)

anonymous — Wed, 06 Feb 2013 09:55:52 GMT

Not quite.

It now complains about:

compile-c-c++ bin.v2\libs\thread\build\msvc-11.0\release\address-model-64\debug-store-database\debug-symbols-on\link-static\runtime-link-static\threading-multi\win32\thread.obj
thread.cpp
D:\boost_1_53_0\boost/thread/win32/shared_mutex.hpp(139) : error C2653: 'chrono' : is not a class or namespace name
D:\boost_1_53_0\boost/thread/win32/shared_mutex.hpp(139) : error C3861: 'try_lock_shared_until': identifier not found
D:\boost_1_53_0\boost/thread/win32/shared_mutex.hpp(139) : error C3861: 'now': identifier not found
D:\boost_1_53_0\boost/thread/win32/shared_mutex.hpp(389) : error C2653: 'chrono' : is not a class or namespace name
D:\boost_1_53_0\boost/thread/win32/shared_mutex.hpp(389) : error C3861: 'try_lock_until': identifier not found
D:\boost_1_53_0\boost/thread/win32/shared_mutex.hpp(389) : error C3861: 'now': identifier not found
D:\boost_1_53_0\boost/thread/future.hpp(354) : warning C4913: user defined binary operator ',' exists but no overload could convert all operands, default built-in binary operator ',' used

I'll qualify those uses of chrono with ::boost:: and post back with the result.

anonymous — Wed, 06 Feb 2013 10:46:41 GMT

Ah... Other uses of chrono::steady_clock seem to be wrapped in BOOST_THREAD_USES_CHRONO. With the patch applied if I add define=BOOST_THREAD_USES_CHRONO to the build command it builds.

It seems I need both the patch and define=BOOST_THREAD_USES_CHRONO. One or other alone doesn't fix the build.

I hope that's useful.

P.S. Just FYI, without the patch but with define=BOOST_THREAD_USES_CHRONO I get:

compile-c-c++ bin.v2\libs\thread\build\msvc-11.0\release\address-model-32\debug-store-database\debug-symbols-on\link-static\runtime-link-static\threading-multi\win32\thread.obj
thread.cpp
D:\boost_1_53_0\boost/thread/win32/shared_mutex.hpp(136) : error C3861: 'timed_lock_shared': identifier not found
D:\boost_1_53_0\boost/thread/future.hpp(354) : warning C4913: user defined binary operator ',' exists but no overload could convert all operands, default built-in binary operator ',' used

viboes — Thu, 07 Feb 2013 18:33:50 GMT

Replying to anonymous:

Ah... Other uses of chrono::steady_clock seem to be wrapped in BOOST_THREAD_USES_CHRONO. With the patch applied if I add define=BOOST_THREAD_USES_CHRONO to the build command it builds.

I guess I see from where the problem comes from. The Jamfile in thread/build defines BOOST_THREAD_DONT_USE_CHRONO. I have made some changes in trunk lastly (pthread part) to ensure that shared_mutex.hpp is not used when thread.cpp is compiled. I plan to do the same for the win32 part, so you should not need to add the define explicitly.

Thanks for this report.

viboes — Thu, 07 Feb 2013 18:38:22 GMT

If you are using the trunk or if you apply the modification introduced in [82757] and add the following patch

svn diff  win32/thread.cpp
Index: win32/thread.cpp
===================================================================
--- win32/thread.cpp	(revision 82706)
+++ win32/thread.cpp	(working copy)
@@ -14,7 +14,7 @@
 #endif
 //#define BOOST_THREAD_VERSION 3
-#include <boost/thread/thread.hpp>
+#include <boost/thread/thread_only.hpp>
 #include <boost/thread/once.hpp>

Does it works without define=BOOST_THREAD_USES_CHRONO?

milestone changed

viboes — Thu, 07 Feb 2013 18:44:34 GMT

milestone To Be Determined → Boost 1.54.0

Committed in trunk revision [82777].

anonymous — Fri, 08 Feb 2013 15:38:39 GMT

Starting with official 1_53_0 release. I applied the 82757 patch.

$ patch.exe -p 2 -i changeset_82757.diff
patching file boost/thread/thread.hpp
patching file boost/thread/thread_only.hpp
patching file boost/thread/future.hpp
patching file libs/thread/src/pthread/thread.cpp
Hunk #1 succeeded at 10 (offset 1 line).
Hunk #2 succeeded at 437 (offset 1 line).

I then applied the 82777 patch.

$ patch.exe  -p 2 -i changeset_82777.diff
patching file boost/thread/win32/shared_mutex.hpp
patching file libs/thread/src/win32/thread.cpp

I then built without define=BOOST_THREAD_USES_CHRONO, and ... it built!

I've not tried linking to the built libraries yet, but I'm sure it will be fine.

Thanks for all your help.

status changed; resolution set

viboes — Wed, 13 Feb 2013 06:44:07 GMT

status assigned → closed
resolution → fixed

Merged [82838]