linking with boost.threads on solaris 8 with gcc 3.0.3
gcc version: 3.0.3 - thread model: posix ld version: GNU ld 2.11.2 (with BFD 2.11.2) boost: 1.27.0 I've applied the unclosed extern "C" fix to once.cpp, removed the unsupported -pthread option from gcc-tools.jam, and built the thread library using jam with no errors. Has anyone compiled anything using this environment that uses boost.threads? A v.simple (completely pointless) test fails for me: #include <exception> #include <iostream> #include <boost/thread/mutex.hpp> int main(int argc, char* argv[]) { try { boost::mutex m; boost::mutex::scoped_lock l(m); } catch(std::exception const& e) { std::cerr << "error: " << e.what() << "\n"; return 1; } } g++ -c -g -I/home/peakalld/boost_1_27_0 main.cpp g++ -o thread_test -L/home/peakalld/boost_1_27_0/libs/thread/build/bin/libboost_thr ead/gcc/debug/runtime-link-dynamic -lboost_thread -lpthread -lposix4 main.o main.o: In function `main': /home/peakalld/development/thread_test/main.cpp:10: undefined reference to `boost::mutex::mutex()' /home/peakalld/development/thread_test/main.cpp:11: undefined reference to `boost::mutex::~mutex()' /home/peakalld/development/thread_test/main.cpp:11: undefined reference to `boost::mutex::~mutex()' main.o: In function `boost::lock_error::~lock_error()': /home/peakalld/boost_1_27_0/boost/thread/detail/lock.hpp(.gnu.linkonce.t._ZN 5boost6detail6thread11scoped_lockINS_5mutexEE4lockEv+0x24): undefined reference to `boost::lock_error::lock_error()' /home/peakalld/boost_1_27_0/boost/thread/detail/lock.hpp(.gnu.linkonce.t._ZN 5boost6detail6thread11scoped_lockINS_5mutexEE6unlockEv+0x24): undefined reference to `boost::lock_error::lock_error()' /home/peakalld/boost_1_27_0/boost/thread/detail/lock.hpp(.gnu.linkonce.t._ZN 5boost6detail6thread8lock_opsINS_5mutexEE4lockERS3_+0x8): undefined reference to `boost::mutex::do_lock()' /home/peakalld/boost_1_27_0/boost/thread/detail/lock.hpp(.gnu.linkonce.t._ZN 5boost6detail6thread8lock_opsINS_5mutexEE6unlockERS3_+0x8): undefined reference to `boost::mutex::do_unlock()' collect2: ld returned 1 exit status make: *** [all] Error 1 Any thoughts appreciated. - Dale.
--- In Boost-Users@y..., "Dale Peakall" <dale.peakall@b...> wrote:
gcc version: 3.0.3 - thread model: posix ld version: GNU ld 2.11.2 (with BFD 2.11.2) boost: 1.27.0
I've applied the unclosed extern "C" fix to once.cpp, removed the unsupported -pthread option from gcc-tools.jam, and built the thread library using jam with no errors.
The extern "C" bug is fixed in CVS. You might want to make sure the gcc-tools.jam problem is a known issue as well.
Has anyone compiled anything using this environment that uses boost.threads?
I don't have any way to compile/test on this platform so all I can offer is general advise. Since Jam works to build the library, does it work to run the test? (Execute Jam in the BOOST_ROOT/libs/thread/test directory.) If this works (hopefully it will) you can use Jam to figure out what command line options are required to link on your platform (execute with the - d+2 switch). Hopefully others will have more information for you. Bill Kempf
--- In Boost-Users@y..., "Dale Peakall" <dale.peakall@b...> wrote:
gcc version: 3.0.3 - thread model: posix ld version: GNU ld 2.11.2 (with BFD 2.11.2) boost: 1.27.0
I've applied the unclosed extern "C" fix to once.cpp, removed the unsupported -pthread option from gcc-tools.jam, and built the thread library using jam with no errors.
The extern "C" bug is fixed in CVS. You might want to make sure the gcc-tools.jam problem is a known issue as well.
Has anyone compiled anything using this environment that uses boost.threads?
I don't have any way to compile/test on this platform so all I can offer is general advise.
Since Jam works to build the library, does it work to run the test? (Execute Jam in the BOOST_ROOT/libs/thread/test directory.) If this works (hopefully it will) you can use Jam to figure out what command line options are required to link on your platform (execute with the - d+2 switch).
Unfortunately, jam fails to build the test app too. The errors reported when trying to link 'test_thread' and are from thread.o: undefined reference to nanosleep undefined reference to sched_yield
Hopefully others will have more information for you.
Lets hope. - Dale.
El Tue, 26 Mar 2002 13:48:18 -0000 "Dale Peakall" <dale.peakall@bit-arts.com> escribió:
gcc version: 3.0.3 - thread model: posix ld version: GNU ld 2.11.2 (with BFD 2.11.2) boost: 1.27.0
I've applied the unclosed extern "C" fix to once.cpp, removed the unsupported -pthread option from gcc-tools.jam, and built the thread library using jam with no errors.
Has anyone compiled anything using this environment that uses boost.threads?
Yes. And it works great. (Ok, we haven't put it to the limit, but...)
A v.simple (completely pointless) test fails for me:
...snip...
g++ -c -g -I/home/peakalld/boost_1_27_0 main.cpp g++ -o thread_test -L/home/peakalld/boost_1_27_0/libs/thread/build/bin/libboost_thr ead/gcc/debug/runtime-link-dynamic -lboost_thread -lpthread -lposix4 main.o main.o: In function `main': ...
Any thoughts appreciated.
In Solaris, the order of the libraries and objects, in link time, _does_ matter. So, instead of: -lboost_thread -lpthread -lposix4 main.o you have to put main.o -lboost_thread -lpthread -lposix4 That way, it works.
- Dale.
-- Raúl Huertas Díaz Redes y Comunicaciones Ingeniero de Sistemas TCP Sistemas e Ingenieria Fernández Caro, 7, 3ª planta Tel.: +34 91 367 32 79 (Ext. 535) Fax: +34 91 407 71 39 rhuertas@tcpsi.es http://www.tcpsi.es
In Solaris, the order of the libraries and objects, in link time, _does_ matter. So, instead of: -lboost_thread -lpthread -lposix4 main.o you have to put main.o -lboost_thread -lpthread -lposix4
That way, it works.
Don't forget that you *must* also compile with -pthreads and link with -pthreads, without this you won't have a thread safe std lib, and probably other problems as well (see gcc -dumpspecs for a full list of what -pthreads does on Solaris). The issue we're grappling with is that when you specify -pthreads in debug mode you will get an unresolved external from std::runtime_error::runtime_error, the fix is to place: #pragma implementation "stdexcept" in one of your source files (this isn't needed for release code though). We should probably get this fix rolled into the thread lib itself at some stage. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm
Don't forget that you *must* also compile with -pthreads and link with -pthreads, without this you won't have a thread safe std lib, and probably other problems as well (see gcc -dumpspecs for a full list of what -pthreads does on Solaris). The issue we're grappling with is that when you specify -pthreads in debug mode you will get an unresolved external from std::runtime_error::runtime_error, the fix is to place:
#pragma implementation "stdexcept"
in one of your source files (this isn't needed for release code though). We should probably get this fix rolled into the thread lib itself at some stage.
Intriguing, as gcc-3.0.3 doesn't have a -pthread argument. I believe you specify the threading model with a configure argument when building gcc now (although I just grabbed pre-built binaries, so I may be wrong). - Dale.
Intriguing, as gcc-3.0.3 doesn't have a -pthread argument. I believe you specify the threading model with a configure argument when building gcc now (although I just grabbed pre-built binaries, so I may be wrong).
I don't know about gcc3, but the way to tell is to do a gcc -dumpspecs | less and then search for "thread", BTW gcc2.95 doesn't have -pthread either: it's spelt -pthreads, note the trailing 's' it makes a difference! For gcc 2.95 -pthreads is the same as: CXXFLAGS=-D_REENTRANT -D_PTHREADS LIBS=-lpthread You are also correct that you have to specify the thread model when you build gcc, that's a precondition for thread safe code, but it's not the end of it, without -pthreads (which then defines _REENTRANT) your std lib allocator won't be thread safe by default (at least on 2.95). BTW I was also wrong about the #pragma implementation hack - it doesn't work :-( Evidently some of the functions from that header are in the std lib, and some aren't, maybe the version of gcc I'm using wasn't built with thread support, I don't know (I'm using the sourceforge compile farm for testing this so I have no control over the gcc install). Whatever we're back to square one on that one, although at least the release version of the thread lib does work. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm
-----Original Message----- From: John Maddock [mailto:john_maddock@compuserve.com] Sent: 29 March 2002 12:22 To: Boost-Users@yahoogroups.com Subject: Re: [Boost-Users] linking with boost.threads on solaris 8 with gcc 3.0.3
Intriguing, as gcc-3.0.3 doesn't have a -pthread argument. I believe you specify the threading model with a configure argument when building gcc now (although I just grabbed pre-built binaries, so I may be wrong).
I don't know about gcc3, but the way to tell is to do a
gcc -dumpspecs | less
and then search for "thread",
BTW gcc2.95 doesn't have -pthread either: it's spelt -pthreads, note the trailing 's' it makes a difference!
For gcc 2.95 -pthreads is the same as: CXXFLAGS=-D_REENTRANT -D_PTHREADS LIBS=-lpthread
You are also correct that you have to specify the thread model when you build gcc, that's a precondition for thread safe code, but it's not the end of it, without -pthreads (which then defines _REENTRANT) your std lib allocator won't be thread safe by default (at least on 2.95).
BTW I was also wrong about the #pragma implementation hack - it doesn't work :-( Evidently some of the functions from that header are in the std lib, and some aren't, maybe the version of gcc I'm using wasn't built with thread support, I don't know (I'm using the sourceforge compile farm for testing this so I have no control over the gcc install). Whatever we're back to square one on that one, although at least the release version of the thread lib does work.
John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm
------------------------ Yahoo! Groups Sponsor ---------------------~--> Tiny Wireless Camera under $80! Order Now! FREE VCR Commander! Click Here - Only 1 Day Left! http://us.click.yahoo.com/nuyOHD/7.PDAA/yigFAA/EbFolB/TM -------------------------------------------------------------- -------~->
Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Sorry for previous straight reply, you no when you've been outlooked :-(
Intriguing, as gcc-3.0.3 doesn't have a -pthread argument. I believe you specify the threading model with a configure argument when building gcc now (although I just grabbed pre-built binaries, so I may be wrong).
I don't know about gcc3, but the way to tell is to do a
gcc -dumpspecs | less
and then search for "thread",
BTW gcc2.95 doesn't have -pthread either: it's spelt -pthreads, note the trailing 's' it makes a difference!
gcc3 does have a -pthreads argument! I just stole the argument from the gcc-tools jam file - this will need to be fixed.
For gcc 2.95 -pthreads is the same as: CXXFLAGS=-D_REENTRANT -D_PTHREADS LIBS=-lpthread
Don't know if gcc3 will have the same problems with stdexcept. - Dale.
gcc3 does have a -pthreads argument! I just stole the argument from the gcc-tools jam file - this will need to be fixed.
It's been fixed in the cvs for a while.
For gcc 2.95 -pthreads is the same as: CXXFLAGS=-D_REENTRANT -D_PTHREADS LIBS=-lpthread
Don't know if gcc3 will have the same problems with stdexcept.
I hope not, but us know. BTW you can tell if your gcc3 build is multithread enabled or not, by doing: gcc -v which will print out the threading model (if any), as well as the spec file location and version number. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm
In Solaris, the order of the libraries and objects, in link time, _does_ matter. So, instead of: -lboost_thread -lpthread -lposix4 main.o you have to put main.o -lboost_thread -lpthread -lposix4
That way, it works.
Don't forget that you *must* also compile with -pthreads and link with -pthreads, without this you won't have a thread safe std lib, and probably other problems as well (see gcc -dumpspecs for a full list of what -pthreads does on Solaris). The issue we're grappling with is
when you specify -pthreads in debug mode you will get an unresolved external from std::runtime_error::runtime_error, the fix is to place:
#pragma implementation "stdexcept"
in one of your source files (this isn't needed for release code
--- In Boost-Users@y..., "John Maddock" <john_maddock@c...> wrote: that though). We
should probably get this fix rolled into the thread lib itself at some stage.
If someone can provide me with a patch I'll be more then happy to fix this in Boost.Threads. Bill Kempf
participants (3)
-
bill_kempf -
Dale Peakall -
John Maddock -
Raul Huertas Diaz