On Thu, Jul 22, 2004 at 02:34:33PM +0200, Christoph Ludwig wrote:
THIS ISSUE IS GOING TO AFFECT USERS, IF BOOST DEVELOPERS STILL DON'T KNOW ABOUT IT THEN IT NEEDS TO BE MADE MORE OBVIOUS. [...] This problem should be obvious to everyone who installs gcc-3.4.1, since you have to select how the standard library will be compiled.
Not if you install a binary version (including RPM or DEB packages). As someone who compiles GCC from source once a week at least, I have never used the --enable-threads=XXX option, until today - and that was only to be able to test the Boost config! There are only two thread models that are supported on Linux: posix and single. Single disables all thread support, posix (the default) causes linker errors in Boost.
FWIW, gcc's configuration switsches w.r.t. threading support didn't change between gcc 3.3.x and 3.4.x. Therefore can reasonably expect the same behavior. (Unless the change is documented in the release notes, of course, but this issue is not mentioned in the release notes of gcc 3.4.{0,1}.
If the problem isn't fixed for 3.4.2 I will push for it to be in the release notes, but that's obviously too late for 3.4.0 and 3.4.1. I will ask that something be added to the release notes on the web site, but that won't affect copies that have already been downloaded and shipped.
Nevertheless, this should be explained in the Release Notes for 1.32. [...]
This doesn't only affect users of new versions of boost, anyone who switches to GCC 3.4, even with an old Boost release, will start getting these linker errors.
Right. However, this is not really a Boost problem. The problem is being caused by the way you installed the standard library. Users of other software will be affected, too. GCC 3.4 still is relatively new, so knowledge about this problem still needs some time to spread.
Debatable. The problem is caused by Boost using an undocumented and non-portable macro to detect a feature that the macro was never designed to indicate. /until/now/ that wasn't a problem and worked, and it's highly unfortunate that GCC changed the "meaning" of that macro (as far as Boost and other libraries are concerned) ... BUT it's still a problem. This has *nothing* to do with how you install GCC, the default configuration and the default installation options (and pre-compiled binaries) will show this problem. It's impossible to configure the stdlib so it won't exhibit this problem - without disabling ALL thread support in the compiler and stdlib. jon -- "Consistency is the last refuge of the unimaginative." - Oscar Wilde