question re linux serialization test results
http://boost.sourceforge.net/regression-logs/cs-Linux.html shows errors in build of the serialization libraries related to pthreads, etc.... I suspect this is a build issue of some sort. When this first occurred I tweaked the jamfile. I suspect there might be some stale *.o files. Thanks for looking into this whoever you are. Robert Ramey
On Wed, Jul 21, 2004 at 04:29:23PM -0700, Robert Ramey wrote:
http://boost.sourceforge.net/regression-logs/cs-Linux.html shows errors in build of the serialization libraries related to pthreads, etc....
This is a known (*) issue with GCC 3.4, you must explicitly define BOOST_DISABLE_THREADS if you are not going to link with -pthread. http://lists.boost.org/MailArchives/boost/msg64550.php and many more THIS ISSUE IS GOING TO AFFECT USERS, IF BOOST DEVELOPERS STILL DON'T KNOW ABOUT IT THEN IT NEEDS TO BE MADE MORE OBVIOUS. How about something on the front page of www.boost.org ? 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. I'll push the GCC developers to say something in the release notes for 3.4.2 if it doesn't get fixed for that release (it's scheduled to, but I don't think it's very high priority) jon -- "It is absurd to divide people into good and bad. People are either charming or tedious." - Oscar Wilde
On Thu, Jul 22, 2004 at 09:28:20AM +0100, Jonathan Wakely wrote:
I'll push the GCC developers to say something in the release notes for 3.4.2 if it doesn't get fixed for that release (it's scheduled to, but I don't think it's very high priority)
I take it back, Benjamin Kosnik has replied to the bug PR saying he considers it high priority, which is good news. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953#c19 jon -- I listen a lot and talk less. You can't learn anything when you're talking. - Bing Crosby
Jonathan Wakely wrote:
On Wed, Jul 21, 2004 at 04:29:23PM -0700, Robert Ramey wrote:
http://boost.sourceforge.net/regression-logs/cs-Linux.html shows errors in build of the serialization libraries related to pthreads, etc....
This is a known (*) issue with GCC 3.4, you must explicitly define BOOST_DISABLE_THREADS if you are not going to link with -pthread.
Right.
http://lists.boost.org/MailArchives/boost/msg64550.php and many more
THIS ISSUE IS GOING TO AFFECT USERS, IF BOOST DEVELOPERS STILL DON'T KNOW ABOUT IT THEN IT NEEDS TO BE MADE MORE OBVIOUS.
FWIW, I did know this when I modified the gcc-3.4.1 toolset a couple of days ago. However, I forgot to remove the test results for gcc-3.4.1 after that. Sorry for that. I'll remove them now, so in the next run the 3.4.1 results should all be fresh. Other test errors show that the gcc-3.4.1 toolset correctly adds the required -pthread option. (e.g. http://tinyurl.com/66sny ) 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. Nevertheless, this should be explained in the Release Notes for 1.32.
How about something on the front page of www.boost.org ?
I don't think this is an issue worthy to be mentioned on the front page.
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. Regards, m
On Thu, Jul 22, 2004 at 01:08:29PM +0200, Martin Wille wrote:
Jonathan Wakely wrote:
This is a known (*) issue with GCC 3.4, you must explicitly define BOOST_DISABLE_THREADS if you are not going to link with -pthread.
Right.
http://lists.boost.org/MailArchives/boost/msg64550.php and many more
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.
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}.
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.
Sure, the problem is neither caused by nor specific to Boost. But I'd be surprised if many developers were aware of the problem. After all, gcc has a command line switch `-pthread'. That makes you assume that compiling without `-pthread' gives you a single threaded binary and that libraries don't silently add dependencies to the pthread-library. (I actually always assumed that gcc - configured with --enable-threads=posix - provides both a single threaded and a multi threaded version of the standard library and that `-pthread' chooses between these two versions, possibly among other things. I only learned that this assumption was wrong when I investigated above problem.) I therefore recommend to put a warning to gcc 3.4 users at a prominent place. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html
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
Christoph Ludwig <cludwig@cdc.informatik.tu-darmstadt.de> writes:
On Thu, Jul 22, 2004 at 01:08:29PM +0200, Martin Wille wrote: [...]
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.
I just installed it on two machines by building it from source and didn't need to make any such explicit selection. I wonder what I ended up with by default? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Thu, Jul 22, 2004 at 11:19:01AM -0400, David Abrahams wrote:
Christoph Ludwig <cludwig@cdc.informatik.tu-darmstadt.de> writes:
On Thu, Jul 22, 2004 at 01:08:29PM +0200, Martin Wille wrote: [...]
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.
I just installed it on two machines by building it from source and didn't need to make any such explicit selection. I wonder what I ended up with by default?
As I said, I build GCC from source very frequently, with various non-default configurations, but have never changed the thread model from the default. You can find out which model was used from the output of "gcc -v". It should include a line saying "Thread model: xxx" The choices if you *do* make an explicit choice, are here: http://gcc.gnu.org/install/configure.html Not all thread models work on all targets. Martin's mail was misleading, a library with posix thread model supports both multithreaded code using pthreads, and single-threaded code. (If that wasn't the case there'd be no problem in the first place). Seems like there are a lot of misunderstandings surrounding this issue. Would it help if I summarised the problem, what's being done, and the workaround? jon -- Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. - M.A. Jackson
Jonathan Wakely wrote:
Martin's mail was misleading, a library with posix thread model supports both multithreaded code using pthreads, and single-threaded code. (If that wasn't the case there'd be no problem in the first place).
Sorry.
Seems like there are a lot of misunderstandings surrounding this issue. Would it help if I summarised the problem, what's being done, and the workaround?
I think it would help. Perhaps this should be put on the website. Regards, m
participants (5)
-
Christoph Ludwig -
David Abrahams -
Jonathan Wakely -
Martin Wille -
Robert Ramey