--- In Boost-Users@y..., "Dale Peakall" 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.

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

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

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.

...

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" 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