[log] Release Candidate 4 released
I'm proud to announce that I've released the fourth candidate of Boost.Log for the review. There were many improvements since the passed year of development. Many of them reflect the discussion of RC3. Here's a short list of major changes: * Substantial documentation improvement. The tutorial section has been reorganized. * Removed rotating file stream. As a replacement, a new file sink has been added, which allows to achieve the same results ans adds a few more features. It is now possible to collect rotated log files in a dedicated directory. * Added a new multifile sink backend. * Added a new ordering asynchronous sink frontend. * The syslog sink backend is now supported on Windows, too. The sink no longer requires native support for POSIX API for syslog, but is able to send syslog packets to a remote server over UDP. * Added support for scoped logging. There is now a distinct log record entity, which is returned by the core as a result of filtring. * Added support for exception control. * Added a new mode of logging, called trivial logging. The more complete change log is available here: http://tinyurl.com/ybcghuf The library with docs, tests and examples has been updated in Boost.Vault: http://tinyurl.com/cm9lum There's SVN repository available on SourceForge project page: http://tinyurl.com/ye23wyh The docs are also available online here: http://tinyurl.com/5e4fd7 Comments are welcome.
2010/1/8 Andrey Semashev <andrey.semashev@gmail.com>
I'm proud to announce that I've released the fourth candidate of Boost.Log for the review.
I hope this library will be up for review some day. This is a much needed library and it looks rather complete (it did last time I looked as well =)). One thing that I miss from the documentation are performance numbers and guides, I think this is a sensitive issue that should be given its own section. By reading the code samples I get some performance concerns only because the code looks 'potentially expensive' (named_scopes, for instance), having the documentation telling me I should not worry together with some tests I could compile and run would elimante such concerns, and spare users like myself some time in doing their own (possibly faulty) performance analysis. Besides this, the documentation I find the documentation good and easy to follow. Edit: I just found the performance folder in libs/test/, maybe it'll tell me something. Have a nice weekend, Christian
On 01/08/2010 08:05 PM, Christian Holmquist wrote:
One thing that I miss from the documentation are performance numbers and guides, I think this is a sensitive issue that should be given its own section. By reading the code samples I get some performance concerns only because the code looks 'potentially expensive' (named_scopes, for instance), having the documentation telling me I should not worry together with some tests I could compile and run would elimante such concerns, and spare users like myself some time in doing their own (possibly faulty) performance analysis. Besides this, the documentation I find the documentation good and easy to follow.
Yes, I intend to add this section to the docs later. There has been some performance testing with comparison to log4cxx. You may find interesting the discussion in this forum thread: http://tinyurl.com/ya85vwf
Edit: I just found the performance folder in libs/test/, maybe it'll tell me something.
This is a half-baked test that I used to measure performance of different sink frontends.
On Fri, Jan 8, 2010 at 3:44 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On 01/08/2010 08:05 PM, Christian Holmquist wrote:
One thing that I miss from the documentation are performance numbers and guides, I think this is a sensitive issue that should be given its own section. By reading the code samples I get some performance concerns only because the code looks 'potentially expensive' (named_scopes, for instance), having the documentation telling me I should not worry together with some tests I could compile and run would elimante such concerns, and spare users like myself some time in doing their own (possibly faulty) performance analysis. Besides this, the documentation I find the documentation good and easy to follow.
Yes, I intend to add this section to the docs later. There has been some performance testing with comparison to log4cxx. You may find interesting the discussion in this forum thread:
Edit: I just found the performance folder in libs/test/, maybe it'll tell me something.
This is a half-baked test that I used to measure performance of different sink frontends.
I would love a comparison between this and Apache's logging framework, in benchmarking speeds, features, coding method, and output formats (with apache's default methods since you can plug in your own into it).
On 01/09/2010 04:45 AM, OvermindDL1 wrote:
Yes, I intend to add this section to the docs later. There has been some performance testing with comparison to log4cxx. You may find interesting the discussion in this forum thread:
I would love a comparison between this and Apache's logging framework, in benchmarking speeds, features, coding method, and output formats (with apache's default methods since you can plug in your own into it).
I don't really like feature-wise comparisons between different things, and Boost.Log and log4cxx are very different in architecture and thus provided features. The comparison will be unfair to both libraries. You can build your opinion by reading their docs and examples and choosing which of them fits you most. As for performance, the mentioned above forum thread should give you the idea. As I said, I will add a performance section to the docs.
On Sat, Jan 9, 2010 at 11:57 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
As for performance, the mentioned above forum thread should give you the idea. As I said, I will add a performance section to the docs.
Andrey, I looked briefly over the aformentioned thread. Just wanted to let you know we did something way simpler here which may or may not help you. Lacking boost.log we created or own logging class which is basically an as-simple-as-possible Syslog client. (I like to process and accumulate there). It used to be boost.format to assemble the messages which proved slower than log4cxx. With spirtt2.1 in 1.41 however we changed to use a karma message generator for this purpose which improved speed dramatically. If you are interested I can donate the generator for your syslog sink. Let me know. Would be syslog only though, but it may still help performance wise. Apart from this, I like the docs. (Could be a little more syslog example though ;-) And the very idea that boost.log is finally appearing. At last! One of the things I've been missing in boost for such a long time. I hope it will enter the trunk soon. Cheers, Stephan
Yes, I intend to add this section to the docs later. There has been some performance testing with comparison to log4cxx. You may find interesting the discussion in this forum thread:
Hi, First of all thanks for submitting this log library to boost, I'm really happy to see you're staying committed to this project. A log library in boost is really something we miss! We're currently using a home-baked asynchronous log system, which is implemented as a lock-free queue sending log packets to a background log thread. Nothing fancy as we don't have to solve a general case like your library. Basically, we have a free function called "emit" that uses old school "printf"-like formatting, it synchronously builds the packet and then sends it to the queue which is eaten by the logging thread. The thread then sends the packet to all the sinks in parallel. Our constraint is that the log engine must not lock at any time and must not allocate memory once the packet is built. Do you think it would be possible for us to simply write a log frontend using the lock-free queue and still respect our constraints? Put differently, has your log-engine other internal locks (apart from potential I/O locks, of course)? Is there dynamic memory allocation going on inside the engine? That is, once I built my "log packet" is there going to be any dynamic memory allocation? Please don't see that as requests, we have very bizarre and specific needs, we'd just like to see if switching to Boost.Log is a possibility. Regards. -- EA __________ Information from ESET NOD32 Antivirus, version of virus signature database 4755 (20100108) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
On 01/09/2010 12:45 PM, Edouard A. wrote:
Our constraint is that the log engine must not lock at any time and must not allocate memory once the packet is built.
Do you think it would be possible for us to simply write a log frontend using the lock-free queue and still respect our constraints? Put differently, has your log-engine other internal locks (apart from potential I/O locks, of course)?
Apart from sinks, there are two possible locks: the logger, if it's a thread-safe one, and the logging core. Both locks are shared ones, so in the common case (you don't modify the core or the logger concurrently while emitting log records) you won't block there. It is possible to block in a sink, if it's a synchronous one. If you have several sinks, the core will attempt to distribute records among them so that blocking is minimized. But you use asynchronous sink, which in Boost.Log also uses a non-blocking queue to pass log records to a dedicated thread. So you should be good here, too.
Is there dynamic memory allocation going on inside the engine? That is, once I built my "log packet" is there going to be any dynamic memory allocation?
Well, that's a complex question. Depends on when to consider the "packet" built. Log records pass several stages before being consumed by sinks, such as filtering, message formatting and sink-specific formatting. The latter one is done in the dedicated thread in case of asynchronous sink. During these stages and in between of them the memory may be allocated. Sinks themselves typically don't allocate memory, but that is not always true.
On Fri, 2010-01-08 at 17:14 +0300, Andrey Semashev wrote:
I'm proud to announce that I've released the fourth candidate of Boost.Log for the review.
Thanks for persisting with this. It would be great to have a truly general purpose logging lib in boost.
* The syslog sink backend is now supported on Windows, too. The sink no longer requires native support for POSIX API for syslog, but is able to send syslog packets to a remote server over UDP.
Cool.
* Added support for scoped logging. There is now a distinct log record entity, which is returned by the core as a result of filtring.
Great. Now I have a few performance and usage issues/questions: I haven't done more than read the docs (oh - I also checked the performance thread on sourceforge),but if I understand correctly the current architecture *always* evaluates all attributes so that filtering can be applied (based on the attribute values). In general attribute evaluation may be expensive. Presumably, in an environment where the performance of *not logging* is important one should be careful to use only low cost attributes. This rather reduces the utilitity of attributes and late formatting - forcing all (expensive) data collection to be by including the collected data in the log message via streaming. I wonder if some form of non-filterable, late evaluated attribute facility should be included as well? Potentially, such a facility could be implemented by returning at attribute value that is merely a proxy that the formatter evaluates? It appears from the example of adding an uptime attribute that the attribute value is heap allocated and a shared ptr returned. Presumably, to avoid issues with allocator performance in general and heap contention in particular, a custom allocator should be used for "lightweight" attributes? Regardless the performance of all attributes provided by the library should be documented (and/or available to the user by running some sort of included benchmark test). Even with the use of constant attributes, is seems filtering performance is inherently not as good as a system which takes advantage of the constant nature of filtering attributes by performing early evaluation of filters and caching the result where possible. Specifically, in the case where the logger "identity" comprised of a set of constant attributes associated with the log, is established at logger construction, it should be possible to determine whether the filter (assuming the filter itself does not change) will always match or never match at that time. Caching this result means that the evaluation of the filter is simply the evaluation of a bool. Potentially, this could be implemented within the proposed logging design by making an "identity" attribute that caches internally in this way and using it as the only attribute for loggers and filters that require high performance when the logger is disabled. Is this a reasonable approach to take? The main problem I see is that in general filters are not constant and this would need some sort of filter/attribute interaction to force reevaluation when the filter is "newer" than the cached bool result. The above is not contrived - the torjo logging lib provided such a feature as the only filtering mechanism aside from a fixed level/severity scheme. This was considered too restrictive/failed to support some use cases. However, the exact use case it did/does support is critical for me, so I need some way to implement it if I am to use your library. Regards Darryl
On 01/10/2010 04:28 PM, Darryl Green wrote:
I haven't done more than read the docs (oh - I also checked the performance thread on sourceforge),but if I understand correctly the current architecture *always* evaluates all attributes so that filtering can be applied (based on the attribute values).
No, not exactly. Attribute values are generated as needed during filtering, so if the filter fails, the unused attributes are not evaluated. If the record passes filtering, the rest of attributes are evaluated. However, one should not count on that behavior in attribute or filter implementation. This is just an internal optimization.
It appears from the example of adding an uptime attribute that the attribute value is heap allocated and a shared ptr returned. Presumably, to avoid issues with allocator performance in general and heap contention in particular, a custom allocator should be used for "lightweight" attributes?
Memory allocation issue is one of my concerns, However, my current point of view is that memory allocator is orthogonal to the library. There may be different solutions, such as using a faster allocator, like tcmalloc from Google, or use memory pooling inside attributes as they generate values. Besides, some attributes don't allocate memory for values.
Even with the use of constant attributes, is seems filtering performance is inherently not as good as a system which takes advantage of the constant nature of filtering attributes by performing early evaluation of filters and caching the result where possible. Specifically, in the case where the logger "identity" comprised of a set of constant attributes associated with the log, is established at logger construction, it should be possible to determine whether the filter (assuming the filter itself does not change) will always match or never match at that time. Caching this result means that the evaluation of the filter is simply the evaluation of a bool. Potentially, this could be implemented within the proposed logging design by making an "identity" attribute that caches internally in this way and using it as the only attribute for loggers and filters that require high performance when the logger is disabled.
Is this a reasonable approach to take? The main problem I see is that in general filters are not constant and this would need some sort of filter/attribute interaction to force reevaluation when the filter is "newer" than the cached bool result.
The other, and the most critical obstacle to follow this approach is that there's no distinction between attribute values that came from loggers and other sets. Also, filters don't interact with attributes, but rather with their values, which often are different and independent objects. Besides, one of the most frequent filtering rejections is when severity level is not high enough, and severity level is not constant. I don't think that caching would help here. But in case of channel logging, I agree, this could give some performance boost. However, right now I don't see how I could implement that without major architecture changes. It's worth thinking over, though.
Andrey Semashev wrote:
I'm proud to announce that I've released the fourth candidate of Boost.Log for the review.
Good to see
There were many improvements since the passed year of development. Many of them reflect the discussion of RC3. Here's a short list of major changes:
* Substantial documentation improvement. The tutorial section has been reorganized. * Removed rotating file stream. As a replacement, a new file sink has been added, which allows to achieve the same results ans adds a few more features. It is now possible to collect rotated log files in a dedicated directory. * Added a new multifile sink backend. * Added a new ordering asynchronous sink frontend. * The syslog sink backend is now supported on Windows, too. The sink no longer requires native support for POSIX API for syslog, but is able to send syslog packets to a remote server over UDP. * Added support for scoped logging. There is now a distinct log record entity, which is returned by the core as a result of filtring. * Added support for exception control. * Added a new mode of logging, called trivial logging.
Is it possible to use any features without compiling - like the trivial logging?
The more complete change log is available here:
The library with docs, tests and examples has been updated in Boost.Vault:
There's SVN repository available on SourceForge project page:
The docs are also available online here:
Comments are welcome.
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. Fyi I used: ./bjam --toolset=gcc --stage-dir=. stage from boost root. ---- common.mkdir bin.v2 common.mkdir bin.v2/libs common.mkdir bin.v2/libs/log common.mkdir bin.v2/libs/log/build common.mkdir bin.v2/libs/log/build/gcc-4.2.4 common.mkdir bin.v2/libs/log/build/gcc-4.2.4/release common.mkdir bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi gcc.compile.c++ bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/attribute_set.o ./boost/intrusive/detail/is_stateful_value_traits.hpp: In instantiation of ‘const int boost::intrusive::function_detector::DetectMember_InstantiationKey_to_value_ptr<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, const boost::log_mt_posix::basic_attribute_set<char>::implementation::node* (boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>::*)(const boost::log_mt_posix::basic_attribute_set<char>::node_base*), const boost::log_mt_posix::basic_attribute_set<char>::implementation::node* (boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>::*)(const boost::log_mt_posix::basic_attribute_set<char>::node_base*)const, const boost::log_mt_posix::basic_attribute_set<char>::implementation::node* (*)(const boost::log_mt_posix::basic_attribute_set<char>::node_base*)>::check’: ./boost/intrusive/detail/is_stateful_value_traits.hpp:67: instantiated from ‘const bool boost::intrusive::detail::is_stateful_value_traits<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link> >::value’ ./boost/intrusive/detail/utilities.hpp:566: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it_impl<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, false>::value’ ./boost/intrusive/detail/utilities.hpp:580: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, unsigned int, false> > >::value’ ./boost/intrusive/detail/list_node.hpp:82: instantiated from ‘const bool boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, unsigned int, false> >, false>::store_container_ptr’ ./boost/intrusive/detail/list_node.hpp:175: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, unsigned int, false> >, false>::members’ ./boost/intrusive/detail/list_node.hpp:184: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, unsigned int, false> >, false>’ libs/log/src/attribute_set.cpp:358: instantiated from ‘typename boost::log_mt_posix::basic_attribute_set<CharT>::iterator boost::log_mt_posix::basic_attribute_set<CharT>::begin() [with CharT = char]’ libs/log/src/attribute_set.cpp:435: instantiated from here ./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 ./boost/intrusive/detail/is_stateful_value_traits.hpp: In instantiation of ‘const int boost::intrusive::function_detector::DetectMember_InstantiationKey_to_node_ptr<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, const boost::log_mt_posix::basic_attribute_set<char>::node_base* (boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>::*)(const boost::log_mt_posix::basic_attribute_set<char>::implementation::node&), const boost::log_mt_posix::basic_attribute_set<char>::node_base* (boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>::*)(const boost::log_mt_posix::basic_attribute_set<char>::implementation::node&)const, const boost::log_mt_posix::basic_attribute_set<char>::node_base* (*)(const boost::log_mt_posix::basic_attribute_set<char>::implementation::node&)>::check’: ./boost/intrusive/detail/is_stateful_value_traits.hpp:67: instantiated from ‘const bool boost::intrusive::detail::is_stateful_value_traits<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link> >::value’ ./boost/intrusive/detail/utilities.hpp:566: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it_impl<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, false>::value’ ./boost/intrusive/detail/utilities.hpp:580: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, unsigned int, false> > >::value’ ./boost/intrusive/detail/list_node.hpp:82: instantiated from ‘const bool boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, unsigned int, false> >, false>::store_container_ptr’ ./boost/intrusive/detail/list_node.hpp:175: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, unsigned int, false> >, false>::members’ ./boost/intrusive/detail/list_node.hpp:184: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, unsigned int, false> >, false>’ libs/log/src/attribute_set.cpp:358: instantiated from ‘typename boost::log_mt_posix::basic_attribute_set<CharT>::iterator boost::log_mt_posix::basic_attribute_set<CharT>::begin() [with CharT = char]’ libs/log/src/attribute_set.cpp:435: instantiated from here ./boost/intrusive/detail/is_stateful_value_traits.hpp:38: error: ‘& boost::intrusive::derivation_value_traits<T, NodeTraits, LinkMode>::to_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]’ is not a valid template argument for type ‘const boost::log_mt_posix::basic_attribute_set<char>::node_base* (*)(const boost::log_mt_posix::basic_attribute_set<char>::implementation::node&)’ because function ‘static typename NodeTraits::const_node_ptr boost::intrusive::derivation_value_traits<T, NodeTraits, LinkMode>::to_node_ptr(typename std::iterator_traits<typename boost::pointer_to_other<typename NodeTraits::node_ptr, const T>::type>::reference) [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 ./boost/intrusive/detail/is_stateful_value_traits.hpp: In instantiation of ‘const int boost::intrusive::function_detector::DetectMember_InstantiationKey_to_value_ptr<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, boost::log_mt_posix::basic_attribute_set<char>::implementation::node* (boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>::*)(boost::log_mt_posix::basic_attribute_set<char>::node_base*), boost::log_mt_posix::basic_attribute_set<char>::implementation::node* (boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>::*)(boost::log_mt_posix::basic_attribute_set<char>::node_base*)const, boost::log_mt_posix::basic_attribute_set<char>::implementation::node* (*)(boost::log_mt_posix::basic_attribute_set<char>::node_base*)>::check’: ./boost/intrusive/detail/is_stateful_value_traits.hpp:67: instantiated from ‘const bool boost::intrusive::detail::is_stateful_value_traits<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link> >::value’ ./boost/intrusive/detail/utilities.hpp:566: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it_impl<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, false>::value’ ./boost/intrusive/detail/utilities.hpp:580: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, unsigned int, false> > >::value’ ./boost/intrusive/detail/list_node.hpp:82: instantiated from ‘const bool boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, unsigned int, false> >, false>::store_container_ptr’ ./boost/intrusive/detail/list_node.hpp:175: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, unsigned int, false> >, false>::members’ ./boost/intrusive/detail/list_node.hpp:184: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, unsigned int, false> >, false>’ libs/log/src/attribute_set.cpp:358: instantiated from ‘typename boost::log_mt_posix::basic_attribute_set<CharT>::iterator boost::log_mt_posix::basic_attribute_set<CharT>::begin() [with CharT = char]’ libs/log/src/attribute_set.cpp:435: instantiated from here ./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 ‘boost::log_mt_posix::basic_attribute_set<char>::implementation::node* (*)(boost::log_mt_posix::basic_attribute_set<char>::node_base*)’ because function ‘static typename boost::pointer_to_other<typename NodeTraits::node_ptr, T>::type boost::intrusive::derivation_value_traits<T, NodeTraits, LinkMode>::to_value_ptr(typename NodeTraits::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 ./boost/intrusive/detail/is_stateful_value_traits.hpp: In instantiation of ‘const int boost::intrusive::function_detector::DetectMember_InstantiationKey_to_node_ptr<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, boost::log_mt_posix::basic_attribute_set<char>::node_base* (boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>::*)(boost::log_mt_posix::basic_attribute_set<char>::implementation::node&), boost::log_mt_posix::basic_attribute_set<char>::node_base* (boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>::*)(boost::log_mt_posix::basic_attribute_set<char>::implementation::node&)const, boost::log_mt_posix::basic_attribute_set<char>::node_base* (*)(boost::log_mt_posix::basic_attribute_set<char>::implementation::node&)>::check’: ./boost/intrusive/detail/is_stateful_value_traits.hpp:67: instantiated from ‘const bool boost::intrusive::detail::is_stateful_value_traits<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link> >::value’ ./boost/intrusive/detail/utilities.hpp:566: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it_impl<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, false>::value’ ./boost/intrusive/detail/utilities.hpp:580: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, unsigned int, false> > >::value’ ./boost/intrusive/detail/list_node.hpp:82: instantiated from ‘const bool boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, unsigned int, false> >, false>::store_container_ptr’ ./boost/intrusive/detail/list_node.hpp:175: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, unsigned int, false> >, false>::members’ ./boost/intrusive/detail/list_node.hpp:184: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<char>::implementation::node, 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, safe_link>, unsigned int, false> >, false>’ libs/log/src/attribute_set.cpp:358: instantiated from ‘typename boost::log_mt_posix::basic_attribute_set<CharT>::iterator boost::log_mt_posix::basic_attribute_set<CharT>::begin() [with CharT = char]’ libs/log/src/attribute_set.cpp:435: instantiated from here ./boost/intrusive/detail/is_stateful_value_traits.hpp:38: error: ‘& boost::intrusive::derivation_value_traits<T, NodeTraits, LinkMode>::to_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]’ is not a valid template argument for type ‘boost::log_mt_posix::basic_attribute_set<char>::node_base* (*)(boost::log_mt_posix::basic_attribute_set<char>::implementation::node&)’ because function ‘static typename NodeTraits::node_ptr boost::intrusive::derivation_value_traits<T, NodeTraits, LinkMode>::to_node_ptr(typename std::iterator_traits<typename boost::pointer_to_other<typename NodeTraits::node_ptr, T>::type>::reference) [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 ./boost/intrusive/detail/is_stateful_value_traits.hpp: In instantiation of ‘const int boost::intrusive::function_detector::DetectMember_InstantiationKey_to_value_ptr<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, const boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node* (boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>::*)(const boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base*), const boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node* (boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>::*)(const boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base*)const, const boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node* (*)(const boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base*)>::check’: ./boost/intrusive/detail/is_stateful_value_traits.hpp:67: instantiated from ‘const bool boost::intrusive::detail::is_stateful_value_traits<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link> >::value’ ./boost/intrusive/detail/utilities.hpp:566: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it_impl<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, false>::value’ ./boost/intrusive/detail/utilities.hpp:580: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, unsigned int, false> > >::value’ ./boost/intrusive/detail/list_node.hpp:82: instantiated from ‘const bool boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, unsigned int, false> >, false>::store_container_ptr’ ./boost/intrusive/detail/list_node.hpp:175: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, unsigned int, false> >, false>::members’ ./boost/intrusive/detail/list_node.hpp:184: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, unsigned int, false> >, false>’ libs/log/src/attribute_set.cpp:358: instantiated from ‘typename boost::log_mt_posix::basic_attribute_set<CharT>::iterator boost::log_mt_posix::basic_attribute_set<CharT>::begin() [with CharT = wchar_t]’ libs/log/src/attribute_set.cpp:438: instantiated from here ./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<wchar_t>::implementation::node, NodeTraits = boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::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<wchar_t>::implementation::node* (*)(const boost::log_mt_posix::basic_attribute_set<wchar_t>::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<wchar_t>::implementation::node, NodeTraits = boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, boost::intrusive::link_mode_type LinkMode = safe_link]’ has not external linkage ./boost/intrusive/detail/is_stateful_value_traits.hpp: In instantiation of ‘const int boost::intrusive::function_detector::DetectMember_InstantiationKey_to_node_ptr<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, const boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base* (boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>::*)(const boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node&), const boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base* (boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>::*)(const boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node&)const, const boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base* (*)(const boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node&)>::check’: ./boost/intrusive/detail/is_stateful_value_traits.hpp:67: instantiated from ‘const bool boost::intrusive::detail::is_stateful_value_traits<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link> >::value’ ./boost/intrusive/detail/utilities.hpp:566: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it_impl<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, false>::value’ ./boost/intrusive/detail/utilities.hpp:580: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, unsigned int, false> > >::value’ ./boost/intrusive/detail/list_node.hpp:82: instantiated from ‘const bool boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, unsigned int, false> >, false>::store_container_ptr’ ./boost/intrusive/detail/list_node.hpp:175: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, unsigned int, false> >, false>::members’ ./boost/intrusive/detail/list_node.hpp:184: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, unsigned int, false> >, false>’ libs/log/src/attribute_set.cpp:358: instantiated from ‘typename boost::log_mt_posix::basic_attribute_set<CharT>::iterator boost::log_mt_posix::basic_attribute_set<CharT>::begin() [with CharT = wchar_t]’ libs/log/src/attribute_set.cpp:438: instantiated from here ./boost/intrusive/detail/is_stateful_value_traits.hpp:38: error: ‘& boost::intrusive::derivation_value_traits<T, NodeTraits, LinkMode>::to_node_ptr [with T = boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, NodeTraits = boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::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<wchar_t>::node_base* (*)(const boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node&)’ because function ‘static typename NodeTraits::const_node_ptr boost::intrusive::derivation_value_traits<T, NodeTraits, LinkMode>::to_node_ptr(typename std::iterator_traits<typename boost::pointer_to_other<typename NodeTraits::node_ptr, const T>::type>::reference) [with T = boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, NodeTraits = boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, boost::intrusive::link_mode_type LinkMode = safe_link]’ has not external linkage ./boost/intrusive/detail/is_stateful_value_traits.hpp: In instantiation of ‘const int boost::intrusive::function_detector::DetectMember_InstantiationKey_to_value_ptr<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node* (boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>::*)(boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base*), boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node* (boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>::*)(boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base*)const, boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node* (*)(boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base*)>::check’: ./boost/intrusive/detail/is_stateful_value_traits.hpp:67: instantiated from ‘const bool boost::intrusive::detail::is_stateful_value_traits<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link> >::value’ ./boost/intrusive/detail/utilities.hpp:566: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it_impl<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, false>::value’ ./boost/intrusive/detail/utilities.hpp:580: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, unsigned int, false> > >::value’ ./boost/intrusive/detail/list_node.hpp:82: instantiated from ‘const bool boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, unsigned int, false> >, false>::store_container_ptr’ ./boost/intrusive/detail/list_node.hpp:175: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, unsigned int, false> >, false>::members’ ./boost/intrusive/detail/list_node.hpp:184: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, unsigned int, false> >, false>’ libs/log/src/attribute_set.cpp:358: instantiated from ‘typename boost::log_mt_posix::basic_attribute_set<CharT>::iterator boost::log_mt_posix::basic_attribute_set<CharT>::begin() [with CharT = wchar_t]’ libs/log/src/attribute_set.cpp:438: instantiated from here ./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<wchar_t>::implementation::node, NodeTraits = boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, boost::intrusive::link_mode_type LinkMode = safe_link]’ is not a valid template argument for type ‘boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node* (*)(boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base*)’ because function ‘static typename boost::pointer_to_other<typename NodeTraits::node_ptr, T>::type boost::intrusive::derivation_value_traits<T, NodeTraits, LinkMode>::to_value_ptr(typename NodeTraits::node_ptr) [with T = boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, NodeTraits = boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, boost::intrusive::link_mode_type LinkMode = safe_link]’ has not external linkage ./boost/intrusive/detail/is_stateful_value_traits.hpp: In instantiation of ‘const int boost::intrusive::function_detector::DetectMember_InstantiationKey_to_node_ptr<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base* (boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>::*)(boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node&), boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base* (boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>::*)(boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node&)const, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base* (*)(boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node&)>::check’: ./boost/intrusive/detail/is_stateful_value_traits.hpp:67: instantiated from ‘const bool boost::intrusive::detail::is_stateful_value_traits<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link> >::value’ ./boost/intrusive/detail/utilities.hpp:566: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it_impl<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, false>::value’ ./boost/intrusive/detail/utilities.hpp:580: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, unsigned int, false> > >::value’ ./boost/intrusive/detail/list_node.hpp:82: instantiated from ‘const bool boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, unsigned int, false> >, false>::store_container_ptr’ ./boost/intrusive/detail/list_node.hpp:175: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, unsigned int, false> >, false>::members’ ./boost/intrusive/detail/list_node.hpp:184: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::derivation_value_traits<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, safe_link>, unsigned int, false> >, false>’ libs/log/src/attribute_set.cpp:358: instantiated from ‘typename boost::log_mt_posix::basic_attribute_set<CharT>::iterator boost::log_mt_posix::basic_attribute_set<CharT>::begin() [with CharT = wchar_t]’ libs/log/src/attribute_set.cpp:438: instantiated from here ./boost/intrusive/detail/is_stateful_value_traits.hpp:38: error: ‘& boost::intrusive::derivation_value_traits<T, NodeTraits, LinkMode>::to_node_ptr [with T = boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, NodeTraits = boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, boost::intrusive::link_mode_type LinkMode = safe_link]’ is not a valid template argument for type ‘boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base* (*)(boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node&)’ because function ‘static typename NodeTraits::node_ptr boost::intrusive::derivation_value_traits<T, NodeTraits, LinkMode>::to_node_ptr(typename std::iterator_traits<typename boost::pointer_to_other<typename NodeTraits::node_ptr, T>::type>::reference) [with T = boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, NodeTraits = boost::log_mt_posix::<unnamed>::ordered_list<boost::log_mt_posix::basic_attribute_set<wchar_t>::implementation::node, boost::log_mt_posix::basic_attribute_set<wchar_t>::node_base>::node_traits, boost::intrusive::link_mode_type LinkMode = safe_link]’ has not external linkage "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -fno-strict-aliasing -DBOOST_ALL_NO_LIB=1 -DBOOST_DATE_TIME_DYN_LINK=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LOG_BUILDING_THE_LIB=1 -DBOOST_LOG_DLL -DBOOST_LOG_USE_NATIVE_SYSLOG=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DDATE_TIME_INLINE -DNDEBUG -I"." -c -o "bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/attribute_set.o" "libs/log/src/attribute_set.cpp" ...failed gcc.compile.c++ bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/attribute_set.o... gcc.compile.c++ bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/attribute_values_view.o gcc.compile.c++ bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/slim_string.o gcc.compile.c++ bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/code_conversion.o gcc.compile.c++ bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/core.o gcc.compile.c++ bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/stream_provider.o gcc.compile.c++ bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/severity_level.o gcc.compile.c++ bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/global_logger_storage.o gcc.compile.c++ bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/named_scope.o gcc.compile.c++ bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/process_id.o gcc.compile.c++ bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/timer.o gcc.compile.c++ bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/exceptions.o gcc.compile.c++ bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/sink_frontends.o gcc.compile.c++ bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/text_ostream_backend.o gcc.compile.c++ bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/text_file_backend.o ./boost/intrusive/detail/is_stateful_value_traits.hpp: In instantiation of ‘const int boost::intrusive::function_detector::DetectMember_InstantiationKey_to_value_ptr<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, const boost::log_mt_posix::sinks::<unnamed>::file_collector* (boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>::*)(const boost::intrusive::list_node<void*>*), const boost::log_mt_posix::sinks::<unnamed>::file_collector* (boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>::*)(const boost::intrusive::list_node<void*>*)const, const boost::log_mt_posix::sinks::<unnamed>::file_collector* (*)(const boost::intrusive::list_node<void*>*)>::check’: ./boost/intrusive/detail/is_stateful_value_traits.hpp:67: instantiated from ‘const bool boost::intrusive::detail::is_stateful_value_traits<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1> >::value’ ./boost/intrusive/detail/utilities.hpp:566: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it_impl<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, false>::value’ ./boost/intrusive/detail/utilities.hpp:580: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, unsigned int, true> > >::value’ ./boost/intrusive/detail/list_node.hpp:82: instantiated from ‘const bool boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, unsigned int, true> >, false>::store_container_ptr’ ./boost/intrusive/detail/list_node.hpp:175: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, unsigned int, true> >, false>::members’ ./boost/intrusive/detail/list_node.hpp:184: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, unsigned int, true> >, false>’ libs/log/src/text_file_backend.cpp:724: instantiated from here ./boost/intrusive/detail/is_stateful_value_traits.hpp:39: error: ‘& boost::intrusive::detail::base_hook_traits<T, NodeTraits, LinkMode, Tag, HookType>::to_value_ptr [with T = boost::log_mt_posix::sinks::<unnamed>::file_collector, NodeTraits = boost::intrusive::list_node_traits<void*>, boost::intrusive::link_mode_type LinkMode = safe_link, Tag = boost::intrusive::default_tag, int HookType = 1]’ is not a valid template argument for type ‘const boost::log_mt_posix::sinks::<unnamed>::file_collector* (*)(const boost::intrusive::list_node<void*>*)’ because function ‘static typename boost::pointer_to_other<typename NodeTraits::node_ptr, const T>::type boost::intrusive::detail::base_hook_traits<T, NodeTraits, LinkMode, Tag, HookType>::to_value_ptr(typename NodeTraits::const_node_ptr) [with T = boost::log_mt_posix::sinks::<unnamed>::file_collector, NodeTraits = boost::intrusive::list_node_traits<void*>, boost::intrusive::link_mode_type LinkMode = safe_link, Tag = boost::intrusive::default_tag, int HookType = 1]’ has not external linkage ./boost/intrusive/detail/is_stateful_value_traits.hpp: In instantiation of ‘const int boost::intrusive::function_detector::DetectMember_InstantiationKey_to_node_ptr<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, const boost::intrusive::list_node<void*>* (boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>::*)(const boost::log_mt_posix::sinks::<unnamed>::file_collector&), const boost::intrusive::list_node<void*>* (boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>::*)(const boost::log_mt_posix::sinks::<unnamed>::file_collector&)const, const boost::intrusive::list_node<void*>* (*)(const boost::log_mt_posix::sinks::<unnamed>::file_collector&)>::check’: ./boost/intrusive/detail/is_stateful_value_traits.hpp:67: instantiated from ‘const bool boost::intrusive::detail::is_stateful_value_traits<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1> >::value’ ./boost/intrusive/detail/utilities.hpp:566: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it_impl<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, false>::value’ ./boost/intrusive/detail/utilities.hpp:580: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, unsigned int, true> > >::value’ ./boost/intrusive/detail/list_node.hpp:82: instantiated from ‘const bool boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, unsigned int, true> >, false>::store_container_ptr’ ./boost/intrusive/detail/list_node.hpp:175: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, unsigned int, true> >, false>::members’ ./boost/intrusive/detail/list_node.hpp:184: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, unsigned int, true> >, false>’ libs/log/src/text_file_backend.cpp:724: instantiated from here ./boost/intrusive/detail/is_stateful_value_traits.hpp:38: error: ‘& boost::intrusive::detail::base_hook_traits<T, NodeTraits, LinkMode, Tag, HookType>::to_node_ptr [with T = boost::log_mt_posix::sinks::<unnamed>::file_collector, NodeTraits = boost::intrusive::list_node_traits<void*>, boost::intrusive::link_mode_type LinkMode = safe_link, Tag = boost::intrusive::default_tag, int HookType = 1]’ is not a valid template argument for type ‘const boost::intrusive::list_node<void*>* (*)(const boost::log_mt_posix::sinks::<unnamed>::file_collector&)’ because function ‘static typename NodeTraits::const_node_ptr boost::intrusive::detail::base_hook_traits<T, NodeTraits, LinkMode, Tag, HookType>::to_node_ptr(typename std::iterator_traits<typename boost::pointer_to_other<typename NodeTraits::node_ptr, const T>::type>::reference) [with T = boost::log_mt_posix::sinks::<unnamed>::file_collector, NodeTraits = boost::intrusive::list_node_traits<void*>, boost::intrusive::link_mode_type LinkMode = safe_link, Tag = boost::intrusive::default_tag, int HookType = 1]’ has not external linkage ./boost/intrusive/detail/is_stateful_value_traits.hpp: In instantiation of ‘const int boost::intrusive::function_detector::DetectMember_InstantiationKey_to_value_ptr<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, boost::log_mt_posix::sinks::<unnamed>::file_collector* (boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>::*)(boost::intrusive::list_node<void*>*), boost::log_mt_posix::sinks::<unnamed>::file_collector* (boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>::*)(boost::intrusive::list_node<void*>*)const, boost::log_mt_posix::sinks::<unnamed>::file_collector* (*)(boost::intrusive::list_node<void*>*)>::check’: ./boost/intrusive/detail/is_stateful_value_traits.hpp:67: instantiated from ‘const bool boost::intrusive::detail::is_stateful_value_traits<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1> >::value’ ./boost/intrusive/detail/utilities.hpp:566: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it_impl<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, false>::value’ ./boost/intrusive/detail/utilities.hpp:580: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, unsigned int, true> > >::value’ ./boost/intrusive/detail/list_node.hpp:82: instantiated from ‘const bool boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, unsigned int, true> >, false>::store_container_ptr’ ./boost/intrusive/detail/list_node.hpp:175: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, unsigned int, true> >, false>::members’ ./boost/intrusive/detail/list_node.hpp:184: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, unsigned int, true> >, false>’ libs/log/src/text_file_backend.cpp:724: instantiated from here ./boost/intrusive/detail/is_stateful_value_traits.hpp:39: error: ‘& boost::intrusive::detail::base_hook_traits<T, NodeTraits, LinkMode, Tag, HookType>::to_value_ptr [with T = boost::log_mt_posix::sinks::<unnamed>::file_collector, NodeTraits = boost::intrusive::list_node_traits<void*>, boost::intrusive::link_mode_type LinkMode = safe_link, Tag = boost::intrusive::default_tag, int HookType = 1]’ is not a valid template argument for type ‘boost::log_mt_posix::sinks::<unnamed>::file_collector* (*)(boost::intrusive::list_node<void*>*)’ because function ‘static typename boost::pointer_to_other<typename NodeTraits::node_ptr, T>::type boost::intrusive::detail::base_hook_traits<T, NodeTraits, LinkMode, Tag, HookType>::to_value_ptr(typename NodeTraits::node_ptr) [with T = boost::log_mt_posix::sinks::<unnamed>::file_collector, NodeTraits = boost::intrusive::list_node_traits<void*>, boost::intrusive::link_mode_type LinkMode = safe_link, Tag = boost::intrusive::default_tag, int HookType = 1]’ has not external linkage ./boost/intrusive/detail/is_stateful_value_traits.hpp: In instantiation of ‘const int boost::intrusive::function_detector::DetectMember_InstantiationKey_to_node_ptr<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, boost::intrusive::list_node<void*>* (boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>::*)(boost::log_mt_posix::sinks::<unnamed>::file_collector&), boost::intrusive::list_node<void*>* (boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>::*)(boost::log_mt_posix::sinks::<unnamed>::file_collector&)const, boost::intrusive::list_node<void*>* (*)(boost::log_mt_posix::sinks::<unnamed>::file_collector&)>::check’: ./boost/intrusive/detail/is_stateful_value_traits.hpp:67: instantiated from ‘const bool boost::intrusive::detail::is_stateful_value_traits<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1> >::value’ ./boost/intrusive/detail/utilities.hpp:566: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it_impl<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, false>::value’ ./boost/intrusive/detail/utilities.hpp:580: instantiated from ‘const bool boost::intrusive::detail::store_cont_ptr_on_it<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, unsigned int, true> > >::value’ ./boost/intrusive/detail/list_node.hpp:82: instantiated from ‘const bool boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, unsigned int, true> >, false>::store_container_ptr’ ./boost/intrusive/detail/list_node.hpp:175: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, unsigned int, true> >, false>::members’ ./boost/intrusive/detail/list_node.hpp:184: instantiated from ‘boost::intrusive::list_iterator<boost::intrusive::list_impl<boost::intrusive::listopt<boost::intrusive::detail::base_hook_traits<boost::log_mt_posix::sinks::<unnamed>::file_collector, boost::intrusive::list_node_traits<void*>, safe_link, boost::intrusive::default_tag, 1>, unsigned int, true> >, false>’ libs/log/src/text_file_backend.cpp:724: instantiated from here ./boost/intrusive/detail/is_stateful_value_traits.hpp:38: error: ‘& boost::intrusive::detail::base_hook_traits<T, NodeTraits, LinkMode, Tag, HookType>::to_node_ptr [with T = boost::log_mt_posix::sinks::<unnamed>::file_collector, NodeTraits = boost::intrusive::list_node_traits<void*>, boost::intrusive::link_mode_type LinkMode = safe_link, Tag = boost::intrusive::default_tag, int HookType = 1]’ is not a valid template argument for type ‘boost::intrusive::list_node<void*>* (*)(boost::log_mt_posix::sinks::<unnamed>::file_collector&)’ because function ‘static typename NodeTraits::node_ptr boost::intrusive::detail::base_hook_traits<T, NodeTraits, LinkMode, Tag, HookType>::to_node_ptr(typename std::iterator_traits<typename boost::pointer_to_other<typename NodeTraits::node_ptr, T>::type>::reference) [with T = boost::log_mt_posix::sinks::<unnamed>::file_collector, NodeTraits = boost::intrusive::list_node_traits<void*>, boost::intrusive::link_mode_type LinkMode = safe_link, Tag = boost::intrusive::default_tag, int HookType = 1]’ has not external linkage ./boost/system/error_code.hpp:208: warning: ‘boost::system::system_category’ defined but not used ./boost/system/error_code.hpp:209: warning: ‘boost::system::generic_category’ defined but not used ./boost/system/error_code.hpp:214: warning: ‘boost::system::posix_category’ defined but not used ./boost/system/error_code.hpp:215: warning: ‘boost::system::errno_ecat’ defined but not used ./boost/system/error_code.hpp:216: warning: ‘boost::system::native_ecat’ defined but not used "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -fno-strict-aliasing -DBOOST_ALL_NO_LIB=1 -DBOOST_DATE_TIME_DYN_LINK=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LOG_BUILDING_THE_LIB=1 -DBOOST_LOG_DLL -DBOOST_LOG_USE_NATIVE_SYSLOG=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DDATE_TIME_INLINE -DNDEBUG -I"." -c -o "bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/text_file_backend.o" "libs/log/src/text_file_backend.cpp" ...failed gcc.compile.c++ bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/text_file_backend.o... gcc.compile.c++ bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/syslog_backend.o gcc.compile.c++ bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/thread_specific.o gcc.compile.c++ bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/trivial.o
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.
On 01/29/2010 08:05 PM, Kim Barrett wrote:
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.
Thanks for the insight. This issue has already been reported to me but I thought this was a compiler bug triggered by Boost.Intrusive. It all ended in the trac ticket #3729. I will add a workaround to Boost.Log.
Kim Barrett wrote:
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, NodeTrait s = 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.
Thanks! Just confirming that 4.3 does indeed work as expected. You saved me a lot of leg work, very much appreciated. Jamie
----- Original Message ----- From: "Andrey Semashev" <andrey.semashev@gmail.com> To: <boost@lists.boost.org> Sent: Friday, January 08, 2010 3:14 PM Subject: [boost] [log] Release Candidate 4 released
I'm proud to announce that I've released the fourth candidate of Boost.Log for the review.
There were many improvements since the passed year of development. Many of them reflect the discussion of RC3. Here's a short list of major changes:
* Added a new ordering asynchronous sink frontend.
The docs are also available online here:
Hi, I'm interested in knowing how the Asynchronous sink frontend is implemented. Do you use a single queue or one queue by thread? In "Why log records are weakly ordered in a multithreaded application?" you present two possible solution: * Strict serialization ( drawback:log records that otherwise could be processed concurrently would have to go serial) * Ordering asynchronous sink frontend (drawback: the order is not completly ensured if a thread blocks during more than the latency parameter) Maybe we can mix both. We can manage with a single log counter that is increased each time a log is done. The time spent to increase this counter atomicaly shouldn't have a deep impact on the concurrency of logs, isn't it? Each log will have a counter attribute that will ensure a complete order of logs. We could have an asynchronous sink that will pass the logs to the back-end in the order given by this counter. Of course this will introduce a latency between the source logging and the time it is given to the back-end sink, but any asynchronous sink will suffer form the same symptom. Do you think that something like this could be included in your library? Good work :), Vicente
On 01/30/2010 07:01 PM, vicente.botet wrote:
Hi, I'm interested in knowing how the Asynchronous sink frontend is implemented. Do you use a single queue or one queue by thread?
There is a single lock-free queue per sink frontend.
In "Why log records are weakly ordered in a multithreaded application?" you present two possible solution:
* Strict serialization ( drawback:log records that otherwise could be processed concurrently would have to go serial)
* Ordering asynchronous sink frontend (drawback: the order is not completly ensured if a thread blocks during more than the latency parameter)
Maybe we can mix both. We can manage with a single log counter that is increased each time a log is done. The time spent to increase this counter atomicaly shouldn't have a deep impact on the concurrency of logs, isn't it? Each log will have a counter attribute that will ensure a complete order of logs. We could have an asynchronous sink that will pass the logs to the back-end in the order given by this counter. Of course this will introduce a latency between the source logging and the time it is given to the back-end sink, but any asynchronous sink will suffer form the same symptom.
Do you think that something like this could be included in your library?
You basically describe the second point (record ordering). The library already supports record ordering in a special frontend. With this frontend one may order records not only by a counter (which will eventually roll over and break the ordering) but by any attribute, time stamps for instance. http://tinyurl.com/ycowsfy
----- Original Message ----- From: "Andrey Semashev" <andrey.semashev@gmail.com> To: <boost@lists.boost.org> Sent: Saturday, January 30, 2010 5:09 PM Subject: Re: [boost] [log] Release Candidate 4 released
On 01/30/2010 07:01 PM, vicente.botet wrote:
Hi, I'm interested in knowing how the Asynchronous sink frontend is implemented. Do you use a single queue or one queue by thread?
There is a single lock-free queue per sink frontend.
Have you considered to have one queue by thread, this could reduce contention as source threads will not share the same queue. In this case the kind of queue you need has only one producer thread and one consumer thread, which has more efficient lock-free implementations (at least this is what I have heard).
In "Why log records are weakly ordered in a multithreaded application?" you present two possible solution:
* Strict serialization ( drawback:log records that otherwise could be processed concurrently would have to go serial)
* Ordering asynchronous sink frontend (drawback: the order is not completly ensured if a thread blocks during more than the latency parameter)
Maybe we can mix both. We can manage with a single log counter that is increased each time a log is done. The time spent to increase this counter atomicaly shouldn't have a deep impact on the concurrency of logs, isn't it? Each log will have a counter attribute that will ensure a complete order of logs. We could have an asynchronous sink that will pass the logs to the back-end in the order given by this counter. Of course this will introduce a latency between the source logging and the time it is given to the back-end sink, but any asynchronous sink will suffer form the same symptom.
Do you think that something like this could be included in your library?
You basically describe the second point (record ordering). The library already supports record ordering in a special frontend.
I know. I've described the drawback of the current approach on my post.
With this frontend one may order records not only by a counter (which will eventually roll over and break the ordering)
You can define an order that takes care of roll over. It is enough that the distance between two samples don't saturate the counter type.
but by any attribute, time stamps for instance.
On some platforms time stamp it is not enough, as several logs can share the same time stamp when the clock is not enough precise. You will need in addition a sequence counter to get a complete order. IMO what the user needs is an complete order related to the time point where the log was sent. I don't see other orders that could interest the user, do you have some examples? Best, Vicente
There is a single lock-free queue per sink frontend.
Have you considered to have one queue by thread, this could reduce contention as source threads will not share the same queue. In this case the kind of queue you need has only one producer thread and one consumer thread, which has more efficient lock-free implementations (at least this is what I have heard).
Yes, I have considered this idea. IMHO, it won't give much performance benefit, compared to a single lock-free queue, unless all your application does is logging alone, from dozens of threads. I did not experiment, though, so I don't have numbers behind myself. I have plans of redesigning the queue in order to allow to limit its growth, which may be required in heavily loaded applications. Per-thread queues would complicate this addition.
With this frontend one may order records not only by a counter (which will eventually roll over and break the ordering)
You can define an order that takes care of roll over. It is enough that the distance between two samples don't saturate the counter type.
Technically, you can't define a reliable distance between counter samples, because it's always possible that a record from a low-priority thread will have the counter value beyond it.
but by any attribute, time stamps for instance.
On some platforms time stamp it is not enough, as several logs can share the same time stamp when the clock is not enough precise. You will need in addition a sequence counter to get a complete order.
Well, from the observer's point of view, records that have the same time stamp were emitted simultaneously. It's undefined which of them happened first, thus no point to define their order in log. One might want to improve the time stamp precision to get a more crisp picture of inter-thread relations. However, you are free to order records as you will. You can define the ordering based both on the time stamp and the record counter.
IMO what the user needs is an complete order related to the time point where the log was sent. I don't see other orders that could interest the user, do you have some examples?
You can't implement a complete order, just the order within an ordering window. But yes, the main aim of this functionality is to maintain chronology of log records.
----- Original Message ----- From: "Andrey Semashev" <andrey.semashev@gmail.com> To: <boost@lists.boost.org> Sent: Saturday, January 30, 2010 8:56 PM Subject: Re: [boost] [log] Release Candidate 4 released
There is a single lock-free queue per sink frontend.
Have you considered to have one queue by thread, this could reduce contention as source threads will not share the same queue. In this case the kind of queue you need has only one producer thread and one consumer thread, which has more efficient lock-free implementations (at least this is what I have heard).
Yes, I have considered this idea. IMHO, it won't give much performance benefit, compared to a single lock-free queue, unless all your application does is logging alone, from dozens of threads. I did not experiment, though, so I don't have numbers behind myself.
I have plans of redesigning the queue in order to allow to limit its growth, which may be required in heavily loaded applications.
This is a good idea. In this kind of context it would be worthwhile to have some mechanism to decide which log records should be lost, in case there is not enough place, severity could be an important factor.
Per-thread queues would complicate this addition.
Why?
With this frontend one may order records not only by a counter (which will eventually roll over and break the ordering)
You can define an order that takes care of roll over. It is enough that the distance between two samples don't saturate the counter type.
Technically, you can't define a reliable distance between counter samples, because it's always possible that a record from a low-priority thread will have the counter value beyond it.
You are right, there is no reliable distance. But in real cases, how many logs can be done before this low-priority thread runs? If you consider this unreliable you can mix time stamps and sequence counters. The distance of two sequence counter having the same time should be quite small.
but by any attribute, time stamps for instance.
On some platforms time stamp it is not enough, as several logs can share the same time stamp when the clock is not enough precise. You will need in addition a sequence counter to get a complete order.
Well, from the observer's point of view, records that have the same time stamp were emitted simultaneously. It's undefined which of them happened first, thus no point to define their order in log. One might want to improve the time stamp precision to get a more crisp picture of inter-thread relations.
This is thru when the logs are done by different threads, but not when they are doen by the sme thread. If the user do log A log B The user expects A is logged before B even if these logs share the same time stamp.
However, you are free to order records as you will. You can define the ordering based both on the time stamp and the record counter.
I agree. I have to say only that I would expect the library provides this by default.
IMO what the user needs is an complete order related to the time point where the log was sent. I don't see other orders that could interest the user, do you have some examples?
You can't implement a complete order, just the order within an ordering window. But yes, the main aim of this functionality is to maintain chronology of log records.
So, do you think it is worth opening this order to the user? Does the library provives at least one order that maintain chronology of log records? If yes, this should be the default behavior. If I have undestood the user needs to state explicitly an order, isn't it? Regards, Vicente
Yes, I have considered this idea. IMHO, it won't give much performance benefit, compared to a single lock-free queue, unless all your application does is logging alone, from dozens of threads. I did not experiment, though, so I don't have numbers behind myself.
I have plans of redesigning the queue in order to allow to limit its growth, which may be required in heavily loaded applications.
This is a good idea. In this kind of context it would be worthwhile to have some mechanism to decide which log records should be lost, in case there is not enough place, severity could be an important factor.
No, I don't plan dropping log records.
Per-thread queues would complicate this addition.
Why?
Because it gets more difficult to determine the total number of queued records. Without introducing a shared locked counter, that is.
Well, from the observer's point of view, records that have the same time stamp were emitted simultaneously. It's undefined which of them happened first, thus no point to define their order in log. One might want to improve the time stamp precision to get a more crisp picture of inter-thread relations.
This is thru when the logs are done by different threads, but not when they are doen by the sme thread. If the user do
log A log B
The user expects A is logged before B even if these logs share the same time stamp.
Log records of the same thread are always ordered. You don't need an ordering frontend to achieve that.
However, you are free to order records as you will. You can define the ordering based both on the time stamp and the record counter.
I agree. I have to say only that I would expect the library provides this by default.
There can not be such a default, since there are no default sinks and attributes. Thus the library cannot guess what attribute values it should use for ordering and what types will they have.
You can't implement a complete order, just the order within an ordering window. But yes, the main aim of this functionality is to maintain chronology of log records.
So, do you think it is worth opening this order to the user? Does the library provives at least one order that maintain chronology of log records? If yes, this should be the default behavior. If I have undestood the user needs to state explicitly an order, isn't it?
The ability to order records is available. Yes, the user has to set up the ordering explicitly, which includes specifying the attribute value name, type and the predicate. And yes, there are tools to simplify this.
On Sat, Jan 30, 2010 at 3:40 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
Per-thread queues would complicate this addition.
Why?
Because it gets more difficult to determine the total number of queued records. Without introducing a shared locked counter, that is.
Boost.Atomic?
On 01/31/2010 01:44 AM, OvermindDL1 wrote:
On Sat, Jan 30, 2010 at 3:40 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
Per-thread queues would complicate this addition.
Why?
Because it gets more difficult to determine the total number of queued records. Without introducing a shared locked counter, that is.
Boost.Atomic?
Yes, it will be extremely useful in a few places of the library once it gets accepted. However, in this particular case introducing a shared counter sort of defeats the whole purpose of thread-specific queues.
----- Original Message ----- From: "Andrey Semashev" <andrey.semashev@gmail.com> To: <boost@lists.boost.org> Sent: Saturday, January 30, 2010 11:40 PM Subject: Re: [boost] [log] Release Candidate 4 released
Yes, I have considered this idea. IMHO, it won't give much performance benefit, compared to a single lock-free queue, unless all your application does is logging alone, from dozens of threads. I did not experiment, though, so I don't have numbers behind myself.
I have plans of redesigning the queue in order to allow to limit its growth, which may be required in heavily loaded applications.
This is a good idea. In this kind of context it would be worthwhile to have some mechanism to decide which log records should be lost, in case there is not enough place, severity could be an important factor.
No, I don't plan dropping log records.
If you limit its growth, what will you do with the new records when there will not be more place?
Per-thread queues would complicate this addition.
Why?
Because it gets more difficult to determine the total number of queued records. Without introducing a shared locked counter, that is.
Sorry to insists, why do you want to determine the total number of queued records?
Well, from the observer's point of view, records that have the same time stamp were emitted simultaneously. It's undefined which of them happened first, thus no point to define their order in log. One might want to improve the time stamp precision to get a more crisp picture of inter-thread relations.
This is thru when the logs are done by different threads, but not when they are doen by the sme thread. If the user do
log A log B
The user expects A is logged before B even if these logs share the same time stamp.
Log records of the same thread are always ordered. You don't need an ordering frontend to achieve that.
Does asynchronous_sink provides already this? How do you ensure Log records of the same thread are always ordered?
However, you are free to order records as you will. You can define the ordering based both on the time stamp and the record counter.
I agree. I have to say only that I would expect the library provides this by default.
There can not be such a default, since there are no default sinks and attributes. Thus the library cannot guess what attribute values it should use for ordering and what types will they have.
Ok I see. Can the creation of a sink force the association of some attributes to the core if not already associated. I would like try to add a ordering_asynchronous_sink that needs an order that depends on two attributes: local_clock and a counter. How can I do this?
You can't implement a complete order, just the order within an ordering window. But yes, the main aim of this functionality is to maintain chronology of log records.
So, do you think it is worth opening this order to the user? Does the library provives at least one order that maintain chronology of log records? If yes, this should be the default behavior. If I have undestood the user needs to state explicitly an order, isn't it?
The ability to order records is available. Yes, the user has to set up the ordering explicitly, which includes specifying the attribute value name, type and the predicate. And yes, there are tools to simplify this.
Please, could you point me to the attribute and the predicate provided by the library that maintain chronology of log records? What other complete orderings do you have in mind the user could want? a concrete case? Just a last question is the counter attribute thread-safe? Best, Vicente
On 31.01.2010 16:40, vicente.botet wrote:
This is a good idea. In this kind of context it would be worthwhile to have some mechanism to decide which log records should be lost, in case there is not enough place, severity could be an important factor.
No, I don't plan dropping log records.
If you limit its growth, what will you do with the new records when there will not be more place?
The frontend will block until the dedicated thread consumes some of the queued records.
Per-thread queues would complicate this addition.
Why?
Because it gets more difficult to determine the total number of queued records. Without introducing a shared locked counter, that is.
Sorry to insists, why do you want to determine the total number of queued records?
Is there another way to implement a bounded queue?
Log records of the same thread are always ordered. You don't need an ordering frontend to achieve that.
Does asynchronous_sink provides already this?
All sink frontends provide this guarantee.
How do you ensure Log records of the same thread are always ordered?
Because I don't reorder them. The only way one could counter that is to specify such an ordering predicate to the ordering frontend, that would reorder records in reverse. But that would simply garble all the output.
Ok I see. Can the creation of a sink force the association of some attributes to the core if not already associated.
No, these operations are not related.
I would like try to add a ordering_asynchronous_sink that needs an order that depends on two attributes: local_clock and a counter. How can I do this?
Please, could you point me to the attribute and the predicate provided by the library that maintain chronology of log records?
There is this utility: http://tinyurl.com/y9sove6 The way it's used with the ordering frontend is shown here: http://tinyurl.com/ycowsfy It does not immediately allow to order by more than one attribute value, but you can write your own ordering function that accepts two records and returns bool: bool my_order(record const& left, record const& right) { ptime left_ts, right_ts; typedef record::values_view_type values_view_type; values_view_type::const_iterator it_left = left.attribute_values().find("TimeStamp"), it_right = right.attribute_values().find("TimeStamp"); if (it_left == left.attribute_values().end() || it_right == right.attribute_values().end()) throw std::runtime_error("Time stamp not found"); left_ts = it_left->second->get< ptime >().get(); right_ts = it_right->second->get< ptime >().get(); if (left_ts < right_ts) return true; else if (left_ts > right_ts) return false else { unsigned int left_counter, right_counter; it_left = left.attribute_values().find("LineNo"), it_right = right.attribute_values().find("LineNo"); if (it_left == left.attribute_values().end() || it_right == right.attribute_values().end()) throw std::runtime_error("Line counter not found"); left_counter = it_left->second->get< unsigned >().get(); right_ts = it_right->second->get< unsigned >().get(); return left_counter < right_counter; } }
What other complete orderings do you have in mind the user could want? a concrete case?
User might want to store log records in an associative container. In this case, it might be useful to have the ability to search for a record by any attribute value attached to it.
Just a last question is the counter attribute thread-safe?
Yes, it is.
----- Original Message ----- From: "Andrey Semashev" <andrey.semashev@gmail.com> To: <boost@lists.boost.org> Sent: Friday, January 08, 2010 3:14 PM Subject: [boost] [log] Release Candidate 4 released
I'm proud to announce that I've released the fourth candidate of Boost.Log for the review.
Hi, I have tried to compile your library with 1.41. While building the library I get this message lib.jam: No such file or directory The file file exist in directory tools/build/v2/tools/types/lib.jam The same message appear when I build asio/test. Do you know why the file is not found? The build continue, but there are a lot of errors First on cygwin-gcc3.4.4 Platforms don't supporting wide characters it would be better to don't define BOOST_LOG_USE_WCHAR_T by default #if !defined(BOOST_LOG_USE_CHAR) && !defined(BOOST_LOG_USE_WCHAR_T) // By default we provide support for both char and wchar_t # define BOOST_LOG_USE_CHAR # define BOOST_LOG_USE_WCHAR_T #endif // !defined(BOOST_LOG_USE_CHAR) && !defined(BOOST_LOG_USE_WCHAR_T) I have added this to the prologue file #ifdef BOOST_NO_STD_WSTRING # undef BOOST_LOG_USE_WCHAR_T #endif and there are yet some places where wstring is used without control, code_conversion.hpp, text_file_backend.cpp, util_string_literal.cpp. After correcting this, I get an error as if the code was looking for some WIN 32 files while I'm compiling on cygwin. gcc.compile.c++ ../../../bin.v2/libs/log/build/gcc-3.4.4/debug/syslog_backend.o In file included from ../../../boost/asio/detail/io_control.hpp:25, from ../../../boost/asio/socket_base.hpp:25, from C:\cygwin\boost_1_41_0\libs\log\src\syslog_backend.cpp:25: ../../../boost/asio/detail/socket_types.hpp:37:5: warning: #warning Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately. ../../../boost/asio/detail/socket_types.hpp:38:5: warning: #warning For example, add -D_WIN32_WINNT=0x0501 to the compiler command line. ../../../boost/asio/detail/socket_types.hpp:39:5: warning: #warning Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP target). ../../../boost/asio/detail/socket_types.hpp:73:5: #error You must add -D__USE_W32_SOCKETS to your compiler options. In file included from ../../../boost/asio/detail/socket_types.hpp:79, from ../../../boost/asio/detail/io_control.hpp:25, from ../../../boost/asio/socket_base.hpp:25, from C:\cygwin\boost_1_41_0\libs\log\src\syslog_backend.cpp:25: /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:103:2: warning: #warning "fd_set and associated macros have been defined in sys/types. This may cause runtime problems with W32 sockets" In file included from ../../../boost/asio/detail/socket_types.hpp:79, from ../../../boost/asio/detail/io_control.hpp:25, from ../../../boost/asio/socket_base.hpp:25, from C:\cygwin\boost_1_41_0\libs\log\src\syslog_backend.cpp:25: /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:635: error: declaration of C function `int gethostname(char*, int)' conflicts with /usr/include/sys/unistd.h:206: error: previous declaration `int gethostname(char*, size_t)' here In file included from ../../../boost/asio/detail/fd_set_adapter.hpp:25, from ../../../boost/asio/detail/select_reactor.hpp:32, from ../../../boost/asio/impl/io_service.ipp:27, from ../../../boost/asio/io_service.hpp:641, from C:\cygwin\boost_1_41_0\libs\log\src\syslog_backend.cpp:26: ../../../boost/asio/detail/win_fd_set_adapter.hpp: In member function `bool boost::asio::detail::win_fd_set_adapter::is_set(boost::asio::detail::socket_type) const': ../../../boost/asio/detail/win_fd_set_adapter.hpp:56: error: `__WSAFDIsSet' undeclared (first use this function) ../../../boost/asio/detail/win_fd_set_adapter.hpp:56: error: (Each undeclared identifier is reported only once for each function it appears in.) The same kind of error is found while I build asio/test, so I suppose that ASIO don't works on cygwin. Could the library be built without the syslog_backend? The last error on cygwin is gcc.compile.c++ ../../../bin.v2/libs/log/build/gcc-3.4.4/debug/trivial.o ../../../boost/log/formatters/wrappers.hpp: In instantiation of `boost::log_st::formatters::wrap_if<char, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::mpl::not_<boost::log_st::formatters::is_formatter<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >': ../../../boost/log/formatters/wrappers.hpp:148: instantiated from `boost::log_st::formatters::wrap_if_not_formatter<char, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >' C:\cygwin\boost_1_41_0\libs\log\src\trivial.cpp:134: instantiated from here ../../../boost/log/formatters/wrappers.hpp:141: error: base `boost::log_st::formatters::wrap_if_c<char, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, true>' with only non-default constructor in class without a constructor ../../../boost/log/formatters/wrappers.hpp: In instantiation of `boost::log_st::formatters::wrap_if_not_formatter<char, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >': C:\cygwin\boost_1_41_0\libs\log\src\trivial.cpp:134: instantiated from here ../../../boost/log/formatters/wrappers.hpp:148: error: base `boost::log_st::formatters::wrap_if<char, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::mpl::not_<boost::log_st::formatters::is_formatter<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >' with only non-default constructor in class without a constructor C:\cygwin\boost_1_41_0\libs\log\src\trivial.cpp: In function `void boost::log_st::trivial::aux::init()': C:\cygwin\boost_1_41_0\libs\log\src\trivial.cpp:134: error: no match for 'operator<<' in 'boost::log_st::formatters::stream_placeholder<CharT>::operator<<(const T&) const [with T = boost::log_st::formatters::fmt_attr<char, unsigned int, boost::log_st::formatters::throw_policy>, CharT = char](((const boost::log_st::formatters::fmt_attr<char, unsigned int, boost::log_st::formatters::throw_policy>&)((const boost::log_st::formatters::fmt_attr<char, unsigned int, boost::log_st::formatters::throw_policy>*)(&boost::log_st::formatters::attr(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&) [with AttributeValueTypesT = unsigned int]())))) << " ["' On MinGW-gcc4.4 I get this error: gcc.compile.c++ ..\..\..\bin.v2\libs\log\build\gcc-mingw-4.4.0\debug\syslog_backend.o In file included from ..\..\../boost/asio/ip/address.hpp:28, from ..\..\../boost/asio/ip/basic_endpoint.hpp:31, from ..\..\../boost/asio/ip/udp.hpp:21, from ..\..\..\libs\log\src\syslog_backend.cpp:27: ..\..\../boost/asio/ip/address_v6.hpp: In constructor 'boost::asio::ip::address_v6::address_v6()': ..\..\../boost/asio/ip/address_v6.hpp:58: warning: missing braces around initializer for 'in6_addr::<anonymous union>' ..\..\../boost/asio/ip/address_v6.hpp:58: warning: missing braces around initializer for 'u_char [16]' ..\..\../boost/asio/ip/address_v6.hpp: In static member function 'static boost::asio::ip::address_v6 boost::asio::ip::address_v6::loopback()': ..\..\../boost/asio/ip/address_v6.hpp:355: warning: missing braces around initializer for 'in6_addr::<anonymous union>' ..\..\../boost/asio/ip/address_v6.hpp:355: warning: missing braces around initializer for 'u_char [16]' gcc.compile.c++ ..\..\..\bin.v2\libs\log\build\gcc-mingw-4.4.0\debug\thread_specific.o gcc.compile.c++ ..\..\..\bin.v2\libs\log\build\gcc-mingw-4.4.0\debug\trivial.o In file included from ..\..\../boost/log/sinks/text_file_backend.hpp:43, from ..\..\..\libs\log\src\trivial.cpp:32: ..\..\../boost/log/detail/universal_path.hpp: In function 'boost::log_st::aux::universal_path boost::log_st::aux::to_universal_path(const PathT&) [with PathT = wchar_t [260]]': ..\..\..\libs\log\src\trivial.cpp:78: instantiated from here ..\..\../boost/log/detail/universal_path.hpp:53: error: request for member 'string' in 'p', which is of non-class type 'const wchar_t [260]' On MSVC Express v9 I get compile-c-c++ ..\..\..\bin.v2\libs\log\test\attr_attribute_set.test\msvc-9.0express\debug\threading-multi\run\attr_attribute_set.obj ... C:\cygwin\boost_1_41_0\boost/test/impl/framework.ipp(485) : warning C4273: 'boost::unit_test::framework::test_unit_aborted' : inconsistent dll linkage C:\cygwin\boost_1_41_0\boost/test/framework.hpp(83) : see previous definition of 'test_unit_aborted' C:\cygwin\boost_1_41_0\boost/test/impl/exception_safety.ipp(513) : error C2491: 'boost::itest::exception_safety' : definition of dllimport function not allowed C:\cygwin\boost_1_41_0\boost/test/impl/execution_monitor.ipp(904) : warning C4535: calling _set_se_translator() requires /EHa ... C:\cygwin\boost_1_41_0\boost/test/impl/logged_expectations.ipp(228) : error C2491: 'boost::itest::logged_expectations' : definition of dllimport function not allowed ... C:\cygwin\boost_1_41_0\boost/test/impl/unit_test_main.ipp(175) : error C2491: 'boost::unit_test::unit_test_main' : definition of dllimport function not allowed ... compile-c-c++ ..\..\..\bin.v2\libs\regex\build\msvc-9.0express\debug\threading-multi\usinstances.obj usinstances.cpp C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\xstring(239) : warning C4506: no definition for inline function 'size_t std::char_traits<_Elem>::length(const _Elem *)' with [ _Elem=unsigned short ] What is wrong? Best, Vicente
On 01/31/2010 04:12 PM, vicente.botet wrote:
I have tried to compile your library with 1.41. While building the library I get this message lib.jam: No such file or directory
The file file exist in directory tools/build/v2/tools/types/lib.jam
The same message appear when I build asio/test. Do you know why the file is not found?
Yes, I see this message, too, regardless of the platform. No idea what it means.
The build continue, but there are a lot of errors
First on cygwin-gcc3.4.4
GCC prior to 4.2 are not supported. Also, I did not strive to support Cygwin or MinGW, so it might need some polishing even with GCC 4.4.
The same kind of error is found while I build asio/test, so I suppose that ASIO don't works on cygwin. Could the library be built without the syslog_backend?
No, there is no such option currently.
On MinGW-gcc4.4 I get this error:
..\..\../boost/log/detail/universal_path.hpp:53: error: request for member 'string' in 'p', which is of non-class type 'const wchar_t [260]'
Strange, I'll look into it.
On MSVC Express v9 I get
compile-c-c++ ..\..\..\bin.v2\libs\log\test\attr_attribute_set.test\msvc-9.0express\debug\threading-multi\run\attr_attribute_set.obj ... C:\cygwin\boost_1_41_0\boost/test/impl/framework.ipp(485) : warning C4273: 'boost::unit_test::framework::test_unit_aborted' : inconsistent dll linkage C:\cygwin\boost_1_41_0\boost/test/framework.hpp(83) : see previous definition of 'test_unit_aborted' C:\cygwin\boost_1_41_0\boost/test/impl/exception_safety.ipp(513) : error C2491: 'boost::itest::exception_safety' : definition of dllimport function not allowed C:\cygwin\boost_1_41_0\boost/test/impl/execution_monitor.ipp(904) : warning C4535: calling _set_se_translator() requires /EHa ... C:\cygwin\boost_1_41_0\boost/test/impl/logged_expectations.ipp(228) : error C2491: 'boost::itest::logged_expectations' : definition of dllimport function not allowed ... C:\cygwin\boost_1_41_0\boost/test/impl/unit_test_main.ipp(175) : error C2491: 'boost::unit_test::unit_test_main' : definition of dllimport function not allowed ... compile-c-c++ ..\..\..\bin.v2\libs\regex\build\msvc-9.0express\debug\threading-multi\usinstances.obj usinstances.cpp C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\xstring(239) : warning C4506: no definition for inline function 'size_t std::char_traits<_Elem>::length(const _Elem *)' with [ _Elem=unsigned short ]
What is wrong?
This looks related to Boost.Test. Not sure I can help with this.
----- Original Message ----- From: "Andrey Semashev" <andrey.semashev@gmail.com> To: <boost@lists.boost.org> Sent: Sunday, January 31, 2010 2:23 PM Subject: Re: [boost] [log] Release Candidate 4 released
On 01/31/2010 04:12 PM, vicente.botet wrote:
The build continue, but there are a lot of errors
First on cygwin-gcc3.4.4
GCC prior to 4.2 are not supported. Also, I did not strive to support Cygwin or MinGW, so it might need some polishing even with GCC 4.4.
The same kind of error is found while I build asio/test, so I suppose that ASIO don't works on cygwin. Could the library be built without the syslog_backend?
No, there is no such option currently.
Could this option be added? Vicente
On 01/31/2010 07:43 PM, vicente.botet wrote:
The same kind of error is found while I build asio/test, so I suppose that ASIO don't works on cygwin. Could the library be built without the syslog_backend?
No, there is no such option currently.
Could this option be added?
Yes. I will add it to the TODO list.
----- Original Message ----- From: "Andrey Semashev" <andrey.semashev@gmail.com> To: <boost@lists.boost.org> Sent: Sunday, January 31, 2010 2:36 PM Subject: Re: [boost] [log] Release Candidate 4 released
On 31.01.2010 16:12, vicente.botet wrote:
..\..\../boost/log/detail/universal_path.hpp:53: error: request for member 'string' in 'p', which is of non-class type 'const wchar_t [260]'
Does the latest SVN checkout fix this?
Yes it does. Thanks, Vicente
----- Original Message ----- From: "vicente.botet" <vicente.botet@wanadoo.fr> To: <boost@lists.boost.org> Sent: Sunday, January 31, 2010 5:38 PM Subject: Re: [boost] [log] Release Candidate 4 released
----- Original Message ----- From: "Andrey Semashev" <andrey.semashev@gmail.com> To: <boost@lists.boost.org> Sent: Sunday, January 31, 2010 2:36 PM Subject: Re: [boost] [log] Release Candidate 4 released
On 31.01.2010 16:12, vicente.botet wrote:
..\..\../boost/log/detail/universal_path.hpp:53: error: request for member 'string' in 'p', which is of non-class type 'const wchar_t [260]'
Does the latest SVN checkout fix this?
Yes it does.
I have needed to build with threading=multi to avoid a lot of errors. Couldn't the Jamfiles take care setting threading=multi when needed? Another error. Where mc can be found? mc.compile ..\..\..\bin.v2\libs\log\build\gcc-mingw-4.4.0\debug\threading-multi\simple_event_log.h 'mc' n'est pas reconnu en tant que commande interne ou externe, un programme ex,cutable ou un fichier de commandes. mc -h "..\..\..\bin.v2\libs\log\build\gcc-mingw-4.4.0\debug\threading-multi" -r "..\..\..\bin.v2\libs\log\build\gcc-mingw-4.4.0\debug\threading-multi" "..\..\..\libs\log\src\simple_event_log.mc" ...failed mc.compile ..\..\..\bin.v2\libs\log\build\gcc-mingw-4.4.0\debug\threading-multi\simple_event_log.h ..\..\..\bin.v2\libs\log\build\gcc-mingw-4.4.0\debug\threading-multi\simple_event_log.rc... Vicente
On 01/31/2010 08:20 PM, vicente.botet wrote:
I have needed to build with threading=multi to avoid a lot of errors. Couldn't the Jamfiles take care setting threading=multi when needed?
threading=multi is a user-side configuration.
Another error. Where mc can be found?
mc.compile ..\..\..\bin.v2\libs\log\build\gcc-mingw-4.4.0\debug\threading-multi\simple_event_log.h 'mc' n'est pas reconnu en tant que commande interne ou externe, un programme ex,cutable ou un fichier de commandes.
mc -h "..\..\..\bin.v2\libs\log\build\gcc-mingw-4.4.0\debug\threading-multi" -r "..\..\..\bin.v2\libs\log\build\gcc-mingw-4.4.0\debug\threading-multi" "..\..\..\libs\log\src\simple_event_log.mc"
...failed mc.compile ..\..\..\bin.v2\libs\log\build\gcc-mingw-4.4.0\debug\threading-multi\simple_event_log.h ..\..\..\bin.v2\libs\log\build\gcc-mingw-4.4.0\debug\threading-multi\simple_event_log.rc...
I believe, from MSVC distribution. Not sure if Express Edition contains it.
----- Original Message ----- From: "Andrey Semashev" <andrey.semashev@gmail.com> To: <boost@lists.boost.org> Sent: Sunday, January 31, 2010 7:35 PM Subject: Re: [boost] [log] Release Candidate 4 released
On 01/31/2010 08:20 PM, vicente.botet wrote:
I have needed to build with threading=multi to avoid a lot of errors. Couldn't the Jamfiles take care setting threading=multi when needed?
threading=multi is a user-side configuration.
if I build with threading=single there are a lot of errors. So maybe you could include different files in the library depending on this feature and execute only the tests that could be run.
Another error. Where mc can be found?
mc.compile ..\..\..\bin.v2\libs\log\build\gcc-mingw-4.4.0\debug\threading-multi\simple_event_log.h 'mc' n'est pas reconnu en tant que commande interne ou externe, un programme ex,cutable ou un fichier de commandes.
mc -h "..\..\..\bin.v2\libs\log\build\gcc-mingw-4.4.0\debug\threading-multi" -r "..\..\..\bin.v2\libs\log\build\gcc-mingw-4.4.0\debug\threading-multi" "..\..\..\libs\log\src\simple_event_log.mc"
...failed mc.compile ..\..\..\bin.v2\libs\log\build\gcc-mingw-4.4.0\debug\threading-multi\simple_event_log.h ..\..\..\bin.v2\libs\log\build\gcc-mingw-4.4.0\debug\threading-multi\simple_event_log.rc...
I believe, from MSVC distribution. Not sure if Express Edition contains it.
I'm building with gcc-mingw-4.4.0, but with msvc-9.0express I get the same error. compile-c-c++ ..\..\..\bin.v2\libs\log\build\msvc-9.0express\debug\threading-multi\trivial.obj trivial.cpp msvc.compile.mc ..\..\..\bin.v2\libs\log\build\msvc-9.0express\debug\threading-multi\simple_event_log.h 'mc' n'est pas reconnu en tant que commande interne ou externe, un programme ex,cutable ou un fichier de commandes. call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 >nul mc -h "..\..\..\bin.v2\libs\log\build\msvc-9.0express\debug\threading-multi" -r "..\..\..\bin.v2\libs\log\build\msvc-9.0express\debug\threading-multi" "..\..\..\libs\log\src\simple_event_log.mc" Any one can help with this? Vicente
On 01/31/2010 10:03 PM, vicente.botet wrote:
if I build with threading=single there are a lot of errors. So maybe you could include different files in the library depending on this feature and execute only the tests that could be run.
What build errors do you get? BTW, if you get errors in compiling examples for single-threaded environment, that's expected.
----- Original Message ----- From: "Andrey Semashev" <andrey.semashev@gmail.com> To: <boost@lists.boost.org> Sent: Sunday, January 31, 2010 9:35 PM Subject: Re: [boost] [log] Release Candidate 4 released
On 01/31/2010 10:03 PM, vicente.botet wrote:
if I build with threading=single there are a lot of errors. So maybe you could include different files in the library depending on this feature and execute only the tests that could be run.
What build errors do you get? BTW, if you get errors in compiling examples for single-threaded environment, that's expected.
I guess you mean examples for multi-threaded environment. When I request to test the library for a single-thread environement, I expect the library compiles and run tests that have a sense only on single-threaded environement. I don't know if you can make explicit which tests must be run when threading=single and when threading=multi with bjam, but IMHO this should be a must. Best, Vicente gcc.compile.c++ ..\..\..\bin.v2\libs\log\example\advanced_usage\gcc-mingw-4.4.0\debug\main.o ..\example\advanced_usage\main.cpp: In function 'int main(int, char**)': ..\example\advanced_usage\main.cpp:98: error: expected initializer before '<' token ..\example\advanced_usage\main.cpp:99: error: 'text_sink' was not declared in this scope ..\example\advanced_usage\main.cpp:99: error: template argument 1 is invalid ..\example\advanced_usage\main.cpp:99: error: invalid type in declaration before '(' token ..\example\advanced_usage\main.cpp:99: error: expected type-specifier before 'text_sink' ..\example\advanced_usage\main.cpp:99: error: expected ')' before 'text_sink' ..\example\advanced_usage\main.cpp:99: error: invalid conversion from 'int*' to 'int' ..\example\advanced_usage\main.cpp:113: error: 'text_sink' is not a class or namespace ..\example\advanced_usage\main.cpp:113: error: expected ';' before 'pBackend' ..\example\advanced_usage\main.cpp:120: error: 'pBackend' was not declared in this scope ..\example\advanced_usage\main.cpp:129: error: no matching function for call to 'boost::log_st::basic_core<char>::add_sink(int&)' ..\..\../boost/log/core/core.hpp:147: note: candidates are: void boost::log_st::basic_core< <template-parameter-1-1> >::add_sink(const boost::shared_ptr<boost::log_st::sinks::sink<CharT> >&) [with CharT = char] ..\example\advanced_usage\main.cpp:143: error: base operand of '->' is not a pointer ..\example\advanced_usage\main.cpp:254: error: base operand of '->' is not a pointer ..\example\advanced_usage\main.cpp:295: error: base operand of '->' is not a pointer gcc.compile.c++ ..\..\..\bin.v2\libs\log\example\async_log\gcc-mingw-4.4.0\debug\main.o ..\example\async_log\main.cpp:55: error: 'logger_mt' in namespace 'src' does not name a type ..\example\async_log\main.cpp:55: error: 'logger_type' does not name a type ..\example\async_log\main.cpp:55: error: ISO C++ forbids declaration of 'logger_type' with no type ..\example\async_log\main.cpp:55: error: 'logger_type' declared as an 'inline' field ..\example\async_log\main.cpp:55: error: expected ';' before '&' token ..\example\async_log\main.cpp:55: error: expected ';' before '}' token ..\example\async_log\main.cpp:55: error: expected initializer before '&' token ..\example\async_log\main.cpp:55: error: 'logger_type' in class 'test_lg' does not name a type ..\example\async_log\main.cpp: In function 'void thread_fun(boost::barrier&)': ..\example\async_log\main.cpp:69: error: 'get_test_lg' was not declared in this scope ..\example\async_log\main.cpp:69: error: invalid type in declaration before '=' token ..\example\async_log\main.cpp:69: error: request for member 'reset' in '_boost_log_record_69', which is of non-class type 'int' ..\example\async_log\main.cpp: In function 'int main(int, char**)': ..\example\async_log\main.cpp:84: error: expected initializer before '<' token ..\example\async_log\main.cpp:85: error: 'sink_t' was not declared in this scope ..\example\async_log\main.cpp:85: error: template argument 1 is invalid ..\example\async_log\main.cpp:85: error: invalid type in declaration before '(' token ..\example\async_log\main.cpp:85: error: expected type-specifier before 'sink_t' ..\example\async_log\main.cpp:85: error: expected ')' before 'sink_t' ..\example\async_log\main.cpp:88: error: invalid conversion from 'int*' to 'int' ..\example\async_log\main.cpp:90: error: base operand of '->' is not a pointer ..\example\async_log\main.cpp:92: error: base operand of '->' is not a pointer ..\example\async_log\main.cpp:101: error: no matching function for call to 'boost::log_st::basic_core<char>::add_sink(int&)' ..\..\../boost/log/core/core.hpp:147: note: candidates are: void boost::log_st::basic_core< <template-parameter-1-1> >::add_sink(const boost::shared_ptr<boost::log_st::sinks::sink<CharT> >&) [with CharT = char] ..\example\async_log\main.cpp:119: error: base operand of '->' is not a pointer ..\example\async_log\main.cpp:120: error: base operand of '->' is not a pointer gcc.compile.c++ ..\..\..\bin.v2\libs\log\example\event_log\gcc-mingw-4.4.0\debug\main.o In file included from ..\example\event_log\main.cpp:35: ..\..\../boost/log/sinks/sync_frontend.hpp:35:2: error: #error Boost.Log: Synchronous sink frontend is only supported in multithreaded environment and up to 108 errors
On 02/01/2010 12:38 AM, vicente.botet wrote:
----- Original Message ----- From: "Andrey Semashev"<andrey.semashev@gmail.com> To:<boost@lists.boost.org> Sent: Sunday, January 31, 2010 9:35 PM Subject: Re: [boost] [log] Release Candidate 4 released
On 01/31/2010 10:03 PM, vicente.botet wrote:
if I build with threading=single there are a lot of errors. So maybe you could include different files in the library depending on this feature and execute only the tests that could be run.
What build errors do you get? BTW, if you get errors in compiling examples for single-threaded environment, that's expected.
I guess you mean examples for multi-threaded environment. When I request to test the library for a single-thread environement, I expect the library compiles and run tests that have a sense only on single-threaded environement. I don't know if you can make explicit which tests must be run when threading=single and when threading=multi with bjam, but IMHO this should be a must.
Oh, I see. I made examples to be built during testing. I'll look into it.
On 02/01/2010 12:38 AM, vicente.botet wrote:
if I build with threading=single there are a lot of errors. So maybe you could include different files in the library depending on this feature and execute only the tests that could be run.
What build errors do you get? BTW, if you get errors in compiling examples for single-threaded environment, that's expected.
I guess you mean examples for multi-threaded environment. When I request to test the library for a single-thread environement, I expect the library compiles and run tests that have a sense only on single-threaded environement. I don't know if you can make explicit which tests must be run when threading=single and when threading=multi with bjam, but IMHO this should be a must.
Fixed in SVN.
participants (9)
-
Andrey Semashev -
Christian Holmquist -
Darryl Green -
Edouard A. -
Jamie Allsop -
Kim Barrett -
OvermindDL1 -
Stephan Menzel -
vicente.botet