boost::thread Compile error with Sun Studio 12
Hi, When I compile the example on the boost::thread documentation (the source is wrapped by a main function): #include <stdlib.h> #include <boost/thread.hpp> /* * */ int main(int argc, char** argv) { boost::system_time const timeout = boost::get_system_time() + boost::posix_time::milliseconds(500); extern bool done; extern boost::mutex m; extern boost::condition_variable cond; boost::unique_lock<boost::mutex> lk(m); while (!done) { if (!cond.timed_wait(lk, timeout)) { throw "timed out"; } } boost:: return (EXIT_SUCCESS); } I get the error CC -library=stlport4 -mt -c -g -I/opt/boost/boost_1_39_0 -o build/Debug/SunStudio-Solaris-x86/thread.o thread.cpp "/opt/boost/boost_1_39_0/boost/thread/detail/thread.hpp", line 344: Error: boost::thread::thread(boost::thread&) is not accessible from boost::move(boost::detail::thread_move_t<boost::thread>). 1 Error(s) detected. So could anyone tell me how to bypass this error, or should the library be updated? -Roman
AMDG Roman Morokutti wrote:
CC -library=stlport4 -mt -c -g -I/opt/boost/boost_1_39_0 -o build/Debug/SunStudio-Solaris-x86/thread.o thread.cpp
"/opt/boost/boost_1_39_0/boost/thread/detail/thread.hpp", line 344: Error: boost::thread::thread(boost::thread&) is not accessible from boost::move(boost::detail::thread_move_t<boost::thread>). 1 Error(s) detected.
So could anyone tell me how to bypass this error, or should the library be updated?
See https://svn.boost.org/trac/boost/ticket/2602. In Christ, Steven Watanabe
Thank you for this hint. As I can tell, this error is still present in 1.39. The patch didn't ease the problem at all because the code now compiles but fails to link due to symbol referencing errors. Bummer! IMHO the Sun Studio compiler should generally be more supported. It is a great compiler for the Solaris platform. -Roman
AMDG Roman Morokutti wrote:
Thank you for this hint. As I can tell, this error is still present in 1.39. The patch didn't ease the problem at all because the code now compiles but fails to link due to symbol referencing errors. Bummer!
Are you linking to the thread library? In Christ, Steven Watanabe
AMDG Roman Morokutti wrote:
Are you linking to the thread library?
Hi Steven,
which one? There isn't any thread*.so.
Well, actually it's libboost_thread*.so
I am afraid that the thread library didn't build. I'll try to build the thread library separately. Thank you again for your hint.
If you check the ticket again, I've attached a fix that works a little bit better than the previous fix. The library compiles fine for me with that patch the current trunk. For reference bash-3.2$ CC -V CC: Sun C++ 5.9 SunOS_i386 2007/11/15 In Christ, Steven Watanabe
Thank you Steven for your help. I have incorporated your patch into the code as shown in trac. This time the library compiled well. The compiler I use is: bash-3.2$ CC -V CC: Sun Ceres C++ 5.10 SunOS_i386 2009/03/06 Usage: CC [ options ] files. Use 'CC -flags' for details A little side node: The code sample I used is from the boost documentation of the thread's library at: http://www.boost.org/doc/libs/1_39_0/doc/html/thread/time.html Here's the code: int main(int argc, char** argv) { boost::system_time const timeout = boost::get_system_time() + boost::posix_time::milliseconds(500); extern bool done = true; extern boost::mutex m; extern boost::condition_variable cond; boost::unique_lock<boost::mutex> lk(m); while (!done) { if (!cond.timed_wait(lk, timeout)) { throw "timed out"; } } return (EXIT_SUCCESS); } But as with the code provided on the net (see link above) where the variables (done, m, cond) are specified with extern, the linker always moaned that it couldn't resolve those symbols. So IMHO this example is not well suited for a standalone example. -Roman
Roman Morokutti <roman.morokutti@gmail.com> writes:
The code sample I used is from the boost documentation of the thread's library at:
http://www.boost.org/doc/libs/1_39_0/doc/html/thread/time.html
Here's the code:
int main(int argc, char** argv) {
boost::system_time const timeout = boost::get_system_time() + boost::posix_time::milliseconds(500);
extern bool done = true; extern boost::mutex m; extern boost::condition_variable cond;
boost::unique_lock<boost::mutex> lk(m); while (!done) { if (!cond.timed_wait(lk, timeout)) { throw "timed out"; } }
return (EXIT_SUCCESS); }
But as with the code provided on the net (see link above) where the variables (done, m, cond) are specified with extern, the linker always moaned that it couldn't resolve those symbols. So IMHO this example is not well suited for a standalone example.
If you declare variables "extern" at block scope then you need to provide a declaration at global scope too. The point of declaring them extern in the example is to say that these variables are accessible to, and used by, code elsewhere in the system. In particular, another thread will lock the mutex, set done to true and then notify the condition variable. Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
Anthony Williams wrote:
If you declare variables "extern" at block scope then you need to provide a declaration at global scope too.
The point of declaring them extern in the example is to say that these variables are accessible to, and used by, code elsewhere in the system. In particular, another thread will lock the mutex, set done to true and then notify the condition variable.
Anthony Thank you for your explanation, Anthony.
As I am relatively new to threading, I have another question regarding your example: Are those variables considered to be for thread local storage. And if, would it be preferable then to use the 'extern' specifier in general? The problem for me (as a novice) on this example is, that it is shown in a very isolated context. Another question: When will the patches for the Sun Compiler be integrated into the trunk. For me, I use the CC 5.10 version, these patches worked well. Roman
Roman Morokutti <roman.morokutti@gmail.com> writes:
Anthony Williams wrote:
If you declare variables "extern" at block scope then you need to provide a declaration at global scope too.
The point of declaring them extern in the example is to say that these variables are accessible to, and used by, code elsewhere in the system. In particular, another thread will lock the mutex, set done to true and then notify the condition variable. Thank you for your explanation, Anthony.
You're welcome.
As I am relatively new to threading, I have another question regarding your example:
Are those variables considered to be for thread local storage. And if, would it be preferable then to use the 'extern' specifier in general?
Thread local storage is manifested in boost with boost::thread_specific_ptr. It's use should be limited to globals (or things that are effectively globals) where each thread must have its own copy. Condition variables, mutexes and the "done" variable from this example are used to communicate between threads, so must be accessible to all threads concerned. Thread local storage is thus a bad idea. The "extern" specifier was trying to convey the idea that these variables are accessible from elsewhere. In general there is very little reason to use extern in practice --- just declare you variables in a shared header, for example.
The problem for me (as a novice) on this example is, that it is shown in a very isolated context.
It was trying to demonstrate a specific feature (using timed wait for a condition variable), not provide a full-featured example of condition variable usage.
When will the patches for the Sun Compiler be integrated into the trunk. For me, I use the CC 5.10 version, these patches worked well.
I will look over them today. Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
Anthony Williams <anthony.ajw@gmail.com> writes:
Roman Morokutti <roman.morokutti@gmail.com> writes:
When will the patches for the Sun Compiler be integrated into the trunk. For me, I use the CC 5.10 version, these patches worked well.
I will look over them today.
I have applied the patch to trunk. Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
Anthony Williams wrote:
Anthony Williams <anthony.ajw@gmail.com> writes:
Roman Morokutti <roman.morokutti@gmail.com> writes:
When will the patches for the Sun Compiler be integrated into the trunk. For me, I use the CC 5.10 version, these patches worked well. I will look over them today.
I have applied the patch to trunk.
Anthony Thank you for your support. I will appreciate your library.
-Roman
participants (3)
-
Anthony Williams -
Roman Morokutti -
Steven Watanabe