Re: [boost] [log] Release Candidate 4 released

Subject: Re: [boost] [log] Release Candidate 4 released
From: Kim Barrett (kab.conundrums_at_[hidden])
Date: 2010-01-29 12:05:25

On Jan 28, 2010, at 8:50 PM, Jamie Allsop wrote:
> I tried building this on Linux using gcc 4.2.4 with boost 1.41. I
> could build boost fine but not this unfortunately. Some (hopefully
> useful) log build output is pasted at the end of this post for your
> convenience.

[... snipped lots of error spew ...]

./boost/intrusive/detail/is_stateful_value_traits.hpp:39: error: ‘& boost::intrusive::derivation_value_traits<T, NodeTraits, LinkMode>::to_value_ptr [with T = boost::log_mt_posix::basic_attribute_set<char>::implementation::node, NodeTraits = boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, boost::log_mt_posix::basic_attribute_set<char>::node_base>::node_traits, boost::intrusive::link_mode_type LinkMode = safe_link]’ is not a valid template argument for type ‘const boost::log_mt_posix::basic_attribute_set<char>::implementation::node* (*)(const boost::log_mt_posix::basic_attribute_set<char>::node_base*)’ because function ‘static typename boost::pointer_to_other<typename NodeTraits::node_ptr, const T>::type boost::intrusive::derivation_value_traits<T, NodeTraits, LinkMode>::to_value_ptr(typename NodeTraits::const_node_ptr) [with T = boost::log_mt_posix::basic_attribute_set<char>::implementation::node, NodeTraits = boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, boost::log_mt_posix::basic_attribute_set<char>::node_base>::node_traits, boost::intrusive::link_mode_type LinkMode = safe_link]’ has not external linkage 

The combination of gcc version (gcc 4.2.x), the reported error reason
(has not external linkage) and the type in the error location
including names in an anonymous namespace (occurrences of <unnamed>)
lead me to believe this is the same as a problem I've encountered a
number of times, most recently yesterday.

The issue seems to be that gcc 4.2 contains (the beginnings of?) an
optimization to exclude symbols from anonymous namespaces from the set
of external linker symbols, as a space optimization, and possibly with
other benefits. Unfortunately, in gcc 4.2 this seems to have been
somewhat botched because these symbols still need to be treated as
having external linkage as far as various C++ language features are
concerned, and that doesn't appear to be done correctly. These
problems seem to have been addressed in gcc 4.3.

The only workaround I've found for this is to change the relevant
anonymous namespace to be a named namespace, typically some "detail"
or "impl" type of namespace since these aren't supposed to be public
names. I've only encountered this problem with gcc 4.2.x; 4.1 doesn't
have the (attempt at) the relevant optimization, and this problem
seems to have been fixed in gcc 4.3.