Re: [boost] question re linux serialization test results

From: Jonathan Wakely (cow_at_[hidden])
Date: 2004-07-22 08:08:48

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