Fix entry_manager constructor not accepting entry_ptr rvalue

[Lastique]

This resolves compilation failures with MinGW.

[viboes]

Thanks for this PR. I can not test it. Hoping that everything that work now will continue to work I will merge it. We could rollback if it introduce some regressions.

[Lastique]

You can see the test results on the regression page:

http://www.boost.org/development/tests/develop/developer/thread.html

Currently, most MinGW testers fail because of this bug like this:

In file included from ../boost/thread/condition_variable.hpp:14:0,
                 from ../boost/thread/future.hpp:20,
                 from ..\libs\thread\test\sync\futures\async\async_executor_pass.cpp:28:
../boost/thread/win32/condition_variable.hpp: In instantiation of 'bool boost::detail::basic_condition_variable::do_wait(lock_type&, boost::detail::timeout) [with lock_type = boost::unique_lock<boost::mutex>]':
../boost/thread/win32/condition_variable.hpp:332:50:   required from here
../boost/thread/win32/condition_variable.hpp:233:67: error: no matching function for call to 'boost::detail::basic_condition_variable::entry_manager::entry_manager(boost::detail::basic_condition_variable::entry_ptr, boost::mutex&)'

http://www.boost.org/development/tests/develop/developer/output/igaztanaga-develop-gcc-4-7c++11-boost-bin-v2-libs-thread-test-async__async_executor_p-test-gcc-mngw-4-7c+-dbg-dbg-symbl-off-thrd-mlt.html

In my local tests on MinGW the problem was fixed with this PR.

[viboes]

What about the other platforms and compilers?

[Lastique]

This is a Windows-only change. I did not test MSVC, but I'm pretty sure it should be fine.

[viboes]

I was thinking in Windows. Antony has promise to test it tome. We will see on the regression test also.

Thanks.

[viboes]

It seems this is working well.

Thanks again, Vicente