August 2017 - Boost - lists.boost.org

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 200

[yap] Re-announcing Yap
by Zach Laine 23 Feb '18

23 Feb '18

I posted 2-3 months ago about Yap, an expression template library I've written that I intend to propose for Boost. This is just a reminder that the library exists, and where to find it. I'm giving a talk about it at C++Now 2017, and some time after that I intend to submit it to the queue. Louis Dionne has offered to serve as review manager when the time comes. You can find the main repo on GitHub: https://github.com/tzlaine/yap And online docs are here: https://tzlaine.github.io/yap Zach

4 6

[beast] Security
by Phil Endecott 13 Dec '17

13 Dec '17

Dear All, To what extent do we think that Beast should be "secure"? I am thinking mostly about handling malicious input. Has it been reviewed by anyone with specific experience of how HTTP can be attacked? Has it been "fuzzed"? Regards, Phil.

6 10

icl mainainership?
by Avi Kivity 21 Nov '17

21 Nov '17

Hello, I see there are 7 pull requests outstanding against icl (including one of mine), but not activity. Joachim, are you still maintaining the library? If not, perhaps someone can step up.

3 4

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

Hi, all I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods. The project at http://stdex.sourceforge.net A git repository at http://nanapro.codeplex.com A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-lib… Is there any interest in this library? Regards Jinhao

8 8

Asciidoc, an alternative for documentation
by Peter Dimov 12 Oct '17

12 Oct '17

I've been experimenting with Asciidoc-based documentation, using Boost.Assert as my guinea pig. The good thing about Asciidoc is that Github shows a preview and you can edit it directly on github.com. This is how the source looks there: https://github.com/boostorg/assert/blob/feature/asciidoc/doc/index.adoc https://github.com/boostorg/assert/blob/feature/asciidoc/doc/assert.adoc https://github.com/boostorg/assert/blob/feature/asciidoc/doc/current_functi… This is how the generated HTML documentation looks, using the default stylesheet, without any customizations on my part: https://rawgit.com/boostorg/assert/feature/asciidoc/doc/html/assert.html And this is how the generated PDF looks: http://pdimov.com/tmp/assert.pdf The tool that produces these is Asciidoctor, http://asciidoctor.org/ .

13 34

Searching for Review Manager for reflection library without macro
by Antony Polukhin 15 Sep '17

15 Sep '17

Hello, PFR is a C++14 library that provides tuple-like methods for aggregate initializables. Library has a set of predefined operators and useful functions for everyday use. Works with user-defined types without any macro or boilerplate code. Library: https://github.com/apolukhin/magic_get Docs: http://apolukhin.github.io/magic_get/ Boost Library Incubator: http://blincubator.com/bi_library/pfr-pod-flat-reflection/?gform_post_id=16… Anyone wishing to become a Review Manager for the library? Boost libraries that may benefit from PFR: * Convert - for out-of-the-box conversions of user types * Hana - for using user types instead of tuples * Intrusive - for reusing unused bits in user provided types * Serialization - for out-of-the-box serialization of user types * Spirit - for putting rule results into user provided types without Phoenix or Fusion macro * Test - for outputting content of user provided types * TypeTraits - for traits like has_unique_object_representations in C++14 -- Best regards, Antony Polukhin

7 9

Re: [boost] Review Request: impl_ptr (pimpl)
by Vladimir Batov 11 Sep '17

11 Sep '17

On 2017-08-19 23:55, Mario Lang wrote: > Vladimir Batov via Boost <boost(a)lists.boost.org> writes: > ... > I got interested enough by this posting so that I ended up doing my own > mini-review just right now :-). And I just wanted to let you know (and > encourage you) that I like this one alot. Keeping the public interface > free of boilerplate is quite nice! Mario, Thank you for your input. Much appreciated... although somewhat early. :-) It was pointed out to me that Boost review procedures changed and a proposal has to be endorsed before it can move to the review stage. So far I do not see it happening... maybe because the list is quiet (overall), maybe because iml_ptr is not good enough to attract that support/endorsement, maybe giving "endorsement" puts too much pressure and people shy away from it. We'll see. > I think for a full boost review, you will probably need to work on: > * The documentation > While I gave it a read, I ended up skipping to your test case because > I wanted to see working example code. > While the current docs have quite some examples, they spend a lot > more > screen space with showing what impl_ptr tries to replace, without > showing a good motivating positive example of how it actually looks > when employed. It also feels like it is spending some time with > marketing speak, while not really showing what it is trying to sell: Yes, I hear you... and I (at least partially) agree with you. First, no code or documentation will ever be to everyone's liking... unless everyone writes their own. Secondly, the documentation reflects many discussions we've had on this list about pimpl. For ex., I had to explicitly add what you call "marketing speak" to plainly explain why IMO pimpl is important. I had to address numerous "why bother" dismissing comments. What you call "marketing speak" I call an architectural view of a project. IMO it's quite different from developer's view that you seem to favor. All views are important... and all of them IMO need to be mentioned to cater for and to convince different readers. Surely, you (as a developer) is free to skip the "marketing speak". Somebody else (an architect and code-reviewer) might decide to skip other bits. No drama. Does it make sense? > The separation between the public interface in a hpp and the template > specialization in a cpp. I think the motivating example should > clearly show what part of the code goes where. Isn't what I did in third and fourth chapters? That said, I'll never be able to write the way you (or somebody else) like it. So, if you feel really strongly about it, please feel free to re-write it as you feel proper and submit. I am more than happy to consider and take others help. Unfortunately, that'll reverse our positions as I (and potential reviewers) might be saying "nuh, not enough "marketing speak" and such. No pressure... but that's an option to shape it up to your liking. > * Namespace: > While the alias is good, I think the whole code should be moved to > boost::, and the detail to boost::detail::impl_ptr::. > I am sort of guessing this will come up in the review. > I might be interested to help with that and submit the renaming PR if > you are open to that. 1) I do agree that the "whole code should be moved to boost::"... when it is part of Boost. Currently it is not. Currently I am on the earliest stage of gathering interest and waiting for "endorsement" and the review manager. 2) As I think I mentioned before impl_ptr is not part of any namespace by design... because the way proxy and implementation are connected, the specialization of impl_ptr<>::implementation. As I also mentioned it is IMO only a "problem" for "purists" but not for "practitioners" as from outside it is all kosher and accessed via boost::impl_ptr. You might be interested in searching for "Pimpl Again?" thread on this list for prev. discussions. Still, it you know a way around it and willing to submit your suggestions, I am certainly open for and most welcome it. But just to state the obvious -- as you do not like every line of code/doc that I write -- that goes both ways.

5 14

[build][wave][thread][date-time] 1.65.0 clang on Windows build failures
by Konstantin Ivlev 02 Sep '17

02 Sep '17

Hi, I am trying to compile boost 1.65.0 on Windows via clang 4.0.1 with the following user-config.jam: using clang : 4.0 : "C:/Program Files/LLVM/bin/clang.exe" : <compileflags>-fmsc-version=1910 <ranlib>"C:/Program Files/LLVM/bin/llvm-ranlib.exe" <archiver>"C:/Program Files/LLVM/bin/llvm-ar.exe" <linkflags>-fuse-ld=lld ; and there are few issues. 1. clang.jam ignores ranlib/archiver settings. currently there is the PR https://github.com/boostorg/build/pull/232 against clang-darwin.jam, and I suppose the same should be applied to the clang-linux.jam. 2. there are numerous errors in boost wave: .\boost/wave/grammars/cpp_expression_grammar.hpp:829:18: error: case value evaluates to -804257404, which cannot be narrowed to type 'unsigned int' [-Wc++11-narrowing] case T_CPPCOMMENT: // contains newline (about 100 errors of such kind for various enumerations) 3. WinAPI-related errors in boost::date_time & boost::thread, e.g. In file included from libs\coroutine\src\windows\stack_traits.cpp:23: In file included from .\boost/thread.hpp:13: In file included from .\boost/thread/thread.hpp:12: In file included from .\boost/thread/thread_only.hpp:15: In file included from .\boost/thread/win32/thread_data.hpp:10: In file included from .\boost/thread/thread_time.hpp:10: In file included from .\boost/date_time/microsec_time_clock.hpp:23: .\boost/date_time/filetime_functions.hpp:57:46: error: conflicting types for 'GetSystemTimeAsFileTime' __declspec(dllimport) void __stdcall GetSystemTimeAsFileTime(FILETIME* lpFileTime); ^ C:\Program Files (x86)\Windows Kits\10\include\10.0.15063.0\um\sysinfoapi.h:159:1: note: previous declaration is here GetSystemTimeAsFileTime( ^ seems like stack_traits.cpp unconditionally includes windows.h, while BOOST_USE_WINDOWS_H is not defined in case of clang build, so filetime_functions.hpp defines its own WinAPI prototypes. probably shall be somehow fixed in boost config? any advice on how to proceed with these issues?

3 4

[iterator] generator_iterator vs. function_input_iterator
by Andrey Semashev 01 Sep '17

01 Sep '17

Hi, There seems to be two nearly equivalent components in Boost.Iterator: generator_iterator (moved from Boost.Utility) and function_input_iterator. Both are input iterators wrapping a function object, which result is used as the dereferenced value. The difference is: - generator_iterator always creates an instance of the element type while function_input_iterator does that lazily; - function_input_iterator uses result_of while generator_iterator relies on C++03 T::result_type - equality comparison is different: generator_iterators compares equal if both refer to the same generator and cached element instances are equal while function_input_iterator uses an additional state (which can be viewed as an index) for comparison instead of the cached element. So basically, they are the same thing. generator_iterator looks a bit more dated and IMHO its comparison implementation is not as robust as that of function_input_iterator, so maybe we should deprecate it?

4 6

[release] Starting 1.65.1
by Daniel James 30 Aug '17

30 Aug '17

Hello all, As no one objected, I'm starting work on a point release. This release should only include fixes and documentation changes, and please keep your changes to a minimum - I'm not looking for any minor changes, such as compiler warning fixes. If I can cleanly incorporate changes from your master branch, let me know the commit hash. Otherwise, please create a branch from the boost-1.65.0 tag called 'fixes/1.65' and cherry pick the required changes onto that branch. All changes should already be included in both your develop and master branches. If a commit doesn't cleanly apply, then we'll have to work something out, but please try to avoid that. If you want any help with this, let me know. The quickbook file for the release notes is at: https://github.com/boostorg/website/blob/master/feed/history/boost_1_65_1.q… I'll set a schedule in the next few days, but I want to get the changes finalised as soon as possible, so don't wait around, I think it will have to be pretty tight. thanks for you help, Daniel

10 27

GitHub issues for superproject
by Olaf van der Spek 30 Aug '17

30 Aug '17

Hi, James wrote: > I would have opened up a github issue on the superproject to track this and resolve it, however the "issues" section is not activated for the superproject. Why's this? IMO it'd be nice to track issues there. As a Boost user I vastly prefer GitHub over Trac. -- Olaf

1 0

Superproject 1.55.0 tags incorrect for libs/uuid?
by James E. King, III 29 Aug '17

29 Aug '17

Hello, Someone reported a discrepancy in boost trac that needs to be investigated by folks on the superproject team. What is claimed is that the superproject tag for boost-1.55 contains commit id 8c395a888c2d77bdc91e956ef24a07c0c87cdd24 for uuid, however this commit id does not exist. The tag id in the boost/uuid repository points to commit 98cf8322aef86e6398dbac7f9cd6bf766621d645. I would have opened up a github issue on the superproject to track this and resolve it, however the "issues" section is not activated for the superproject. https://svn.boost.org/trac10/ticket/13071 Instructions given to reproduce the issue are as follows: git clone https://github.com/boostorg/boost.git cd boost git submodule init libs/uuid git checkout boost-1.55.0 git submodule update libs/uuid and the last step will fail with: fatal: reference is not a tree: 8c395a888c2d77bdc91e956ef24a07c0c87cdd24 Unable to checkout '8c395a888c2d77bdc91e956ef24a07c0c87cdd24' in submodule path 'libs/uuid' Thanks, Jim

2 1

Interest in thermodynamic properties of water and steam
by Belcourt, Kenneth 29 Aug '17

29 Aug '17

Hi, Would there be any interest in an implementation of the IAPWS-95 in Boost? Here’s the reference: The IAPWS Formulation 1995 for the Thermodynamic Properties of Ordinary Water Substance for General and Scientific Use. Authors: W. Wagner and A. Pruss J. Phys. Chem. Ref. Data, Vol. 31, No. 2, 2002, pages 387-535 For those with access to the paper, the code reproduces Table 6.6 (results agree to all published digits), as well as well significant parts of both Table 13.1 (vapor-liquid phase boundary properties as function of temperature) and Table 13.2 (properties of water in single-phase as function of temperature and density for pressures in range of 0.05 MPa to 1000 MPa). Also implemented are the full set of algorithms in Table 6.3, including pressure, enthalpy, entropy, sound speed, heat capacities. There’s also an algorithm for computing the thermal saturation properties (pressure, liquid and vapor densities), given the saturation temperature. At present the code has a required dependency on Boost.Units and is about 2k loc. If you're interested in this, feel free to reply or contact me directly. — Noel Belcourt [1] http://www.iapws.org

7 10

Question/Remark to your include/boost/numeric/ublas/lu.hpp
by Ziehe, Dieter 29 Aug '17

29 Aug '17

Dear development community, first of all, thanks for your work, I use boost sometimes to ease from it in my development of math algorithm. Normally I try and check your code and documentation till it works (for example Edmonds karp, remez ...) But now I came to one point, which I don't understand and only workarounded it (although I'm a mathematician and the topic LU-Decomposition is easy). My Problem is lu.hpp:: lu_factorize and this part : (*) #if BOOST_UBLAS_TYPE_CHECK swap_rows (pm, cm); BOOST_UBLAS_CHECK (singular != 0 || detail::expression_type_check (prod (triangular_adaptor<matrix_type, unit_lower> (m), triangular_adaptor<matrix_type, upper> (m)), cm), internal_logic ()); #endif Despite the fact, that I can BOOST_UBLAS_TYPE_CHECK switch off (with BOOST_UBLAS_NDEBUG) I don't understand the sense of these lines. As far as I know, LU is in every case possible, either a matrix is singular or not. For example the ZERO-Matrix is also LU- decomposable (Solution ZERO-Matrix and Identity Matrix). And so, IMHO the lines are too strong for this situation. These lines lead in remez to an Exception : remez failed with exception: internal logic , but the remez algorithm is right (without BOOST_UBLAS_TYPE_CHECK) I got the correct results. Is it possible to weaken the lines (*) to a hint only (the return-value singular is also available for other user, who need regularity). Maybe I'm wrong. But if so, I'd like to know the argument, which lead to such strong reaction in the normal case of singular Matrix inside the LU-Algorithm ? I'm looking forward to hear from you. Many thanks. Dieter from Berlin

1 0

[Intrusive]
by degski 28 Aug '17

28 Aug '17

I having trouble understanding the documentation of Boost.Intrusive. I'm referring to this section in particular: http://www.boost.org/doc/libs/1_65_0/doc/html/intrusive/intrusive_vs_nontru… "The main difference between intrusive containers and non-intrusive containers is that in C++ non-intrusive containers store *copies* of values passed by the user." This is confusing, as that might not be true in case of C++11 and up. Does (or rather, can) move-construction invalidate the use case for Intrusive containers? "On the other hand, an intrusive container does not store copies of passed objects, but it stores the objects themselves. The additional data needed to insert the object in the container must be provided by the object itself." But then in the example for slist, it seems from the example code that (a) pointer(s) to the original object are stored (and makes it look like the object), but that's not what I read from the quoted text. class MyClass{ MyClass *next; MyClass *previous; //Other members...}; int main(){ acme_intrusive_list<MyClass> list; MyClass myclass; list.push_back(myclass); //"myclass" object is stored in the list assert(&myclass == &list.front()); return 0;} I would like to ask for somebody to confirm I'm right, or explain to me in language (palatable to a thick user) what is actually stored (in terms of implementation). Thanks in advance, degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

5 19

[detail] boost/detail/utf8_codecvt_facet.hpp broken by recent change
by Beman Dawes 28 Aug '17

28 Aug '17

boost/detail/utf8_codecvt_facet.hpp fails to compile for STL's MinGW distro from https://nuwen.net/mingw.html The error message is: ..\..\../boost/detail/utf8_codecvt_facet.hpp:117:29: error: function 'boost::filesystem::detail::utf8_codecvt_facet::~utf8_codecvt_facet()' definition is marked dllimport virtual BOOST_UTF8_DECL ~utf8_codecvt_facet(){} The problem (on develop) is caused by Robert Ramey's Aug 13 commit 73c12230c31a851c15ecb9a649468425ebd92f8e "adjustment to avoid linking problem: vtable not found found for ~utf8_codecvt_facet.hpp" which added "BOOST_UTF8_DECL" to line 117. This is breaking my local filesystem tests for GCC/MinGW. If the change is reverted, the tests start passing again. Robert, could you please revert the change? I can also to it, but thought you needed to be alerted first so you can revisit whatever you were trying to fix. Thanks, --Beman

4 6

[release] 1.65.1 closing on Thursday
by Daniel James 28 Aug '17

28 Aug '17

Hi, I've added a schedule for 1.65.1 to the calendar: http://www.boost.org/development/ I think it should be possible to get the changes ready in the next two days, although the schedule is a little flexible. I might also release a little early if everything goes smoothly. We don't want to spend too much time on this. Daniel

2 2

[iterator] What documentation is actual?
by Andrey Semashev 27 Aug '17

27 Aug '17

Hi, While moving next_prior.hpp to Boost.Iterator I've noticed that thete are basically two versions of the documentation in Boost.Iterator: rst and QuickBook. It seems like QuickBook is in progress of being written and is largely a conversion of rst, but is incomplete in some places. I'd like to ask what's the plan about it? Since I don't know rst I converted the original documentation of next_prior.hpp to QuickBook and added it to the current QuickBook docs. I also converted advance() and distance() docs to QuickBook and fixed a few problems in the docs so that it is at least browsable and readable. If we have no plans to switch to QuickBook then I suppose it is better to remove them to avoid confusion. Also, someone has to convert next_prior.hpp docs to rst (I don't know how to do this).

3 8

Purchasing Travis Resources for boostorg (was Re: [1.65.0] Point release?)
by Tom Kent 27 Aug '17

27 Aug '17

On Sat, Aug 26, 2017 at 1:16 PM, Daniel James via Boost < boost(a)lists.boost.org> wrote: > On 26 August 2017 at 18:02, Peter Dimov via Boost <boost(a)lists.boost.org> > wrote: > > Daniel James wrote: > > > But we don't rely that much on the testers nowadays, so this would be > less > > of an issue. > > I do. The turnaround on Travis is pretty terrible at the moment, and > that's going to get worse as more modules use it. While I'm a big fan of Boost's test system, and believe that it is an awesome resource that can't be replicated on the common CI services (lots of platforms and compiler versions/configs!), I also think that good per-commit CI on a service like travis is hugely important. Maybe someone should present a proposal to the steering committee to start paying for boostorg's account to have additional build resources? Tom

9 9

[1.65.0] Point release?
by Daniel James 27 Aug '17

27 Aug '17

Hello all, What do you think about having a point release? I tried asking the other release managers but didn't get any reply. Some are away, and I don't known when they will be available again. I think we have to decide soon, as it's holding up development. This would deal with the issues in thread, context, fiber, and possibly others. I've added patches to the release notes: http://www.boost.org/users/history/version_1_65_0.html A point release should take a week or two, perhaps more if we include other changes. thanks, Daniel

7 18

[Boost-build] Broken installation with `./b2 --prefix=/tmp/boost --with-stacktrace install`
by Antony Polukhin 26 Aug '17

26 Aug '17

Hi, People complain about the broken installation. Command `./b2 --prefix=/tmp/boost --with-stacktrace install` does not copy the boost/stacktrace/detail/push_options.pp and boost/stacktrace/detail/pop_options.pp files into the destination folder. See https://github.com/boostorg/stacktrace/issues/29 How this could be fixed? Is that a b2 issue? -- Best regards, Antony Polukhin

3 2

boost.process 1.64.0 and 1.65.0 are equal
by Egor Pugin 26 Aug '17

26 Aug '17

Hi, See https://github.com/boostorg/process/releases Both boost/process 1.64.0 and 1.65.0 have same commit 4075371. Looks like that boost process 1.65.0 was not updated. Is this a bug or feature? For reference, this was detected in https://github.com/klemens-morgenstern/boost-process/issues/121 -- Egor Pugin

2 1

Important Regression of Boost.Thread on Windows
by Vicente J. Botet Escriba 26 Aug '17

26 Aug '17

Hi, there is an important regression of Boost Thread on Windows https://github.com/boostorg/thread/issues/130 windows: Bug in boost::condition_variable on Windows Please, merge these two patches 1 https://github.com/boostorg/thread/commit/fdc0cbcd8ce8f34a19c7cdaf6f1fa679f… 2 https://github.com/boostorg/thread/commit/395e3d786bc1dce9c60eb84da85f5845a… I've sent a PR for the boost-1.65 release notes https://github.com/boostorg/website/pull/267 If there is a 1.65.1 point release, this issue should be a good candidate. Sorry for the disturbance Vicente

1 0

1.65 build failure on FreeBSD 11.1
by rleigh＠codelibre.net 26 Aug '17

26 Aug '17

The error is "boost/stacktrace/detail/collect_unwind.ipp:55:7: error: no member named '_Unwind_Backtrace' in the global namespace". The details are below. A creeping Linux-ism? Regards, Roger $ clang++ --version FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) Target: x86_64-unknown-freebsd11.1 Thread model: posix InstalledDir: /usr/bin $ uname -a FreeBSD brill 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309: Fri Jul 21 02:08:28 UTC 2017 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 -- Building boost (Unix) with toolset=clang cxxflags= -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include linkflags= -L/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/lib Performing configuration checks - 32-bit : no - 64-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes - symlinks supported : yes - C++11 mutex : no - lockfree boost::atomic_flag : yes - Boost.Config Feature Check: cxx11_auto_declarations : no - Boost.Config Feature Check: cxx11_constexpr : no - Boost.Config Feature Check: cxx11_defaulted_functions : no - Boost.Config Feature Check: cxx11_final : no - Boost.Config Feature Check: cxx11_hdr_mutex : no - Boost.Config Feature Check: cxx11_hdr_tuple : no - Boost.Config Feature Check: cxx11_lambdas : no - Boost.Config Feature Check: cxx11_noexcept : no - Boost.Config Feature Check: cxx11_nullptr : no - Boost.Config Feature Check: cxx11_rvalue_references : no - Boost.Config Feature Check: cxx11_template_aliases : no - Boost.Config Feature Check: cxx11_thread_local : no - Boost.Config Feature Check: cxx11_variadic_templates : no - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : yes - bzip2 : yes - lzma : yes - iconv (libc) : yes - icu : yes - xlocale supported : yes - native-atomic-int32-supported : yes - native-syslog-supported : yes - pthread-supports-robust-mutexes : yes - compiler-supports-visibility : yes - compiler-supports-ssse3 : yes - compiler-supports-avx2 : yes - gcc visibility : yes - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. - libbacktrace builds : no - addr2line builds : yes - WinDbg builds : no - WinDbgCached builds : no Component configuration: - atomic : building - chrono : building - container : building - context : building - coroutine : building - date_time : building - exception : building - fiber : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - log : building - math : building - metaparse : building - mpi : building - program_options : building - python : not building - random : building - regex : building - serialization : building - signals : building - stacktrace : building - system : building - test : building - thread : building - timer : building - type_erasure : building - wave : building [...] clang-linux.compile.c++.without-pth bin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi/addr2line.o "/usr/bin/CC" -c -x c++ -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include -O3 -Wno-inline -Wall -pedantic -pthread -fPIC -m64 -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include -DBOOST_ALL_NO_LIB=1 -DBOOST_STACKTRACE_DYN_LINK=1 -DNDEBUG -I"." -o "bin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi/addr2line.o" "libs/stacktrace/build/../src/addr2line.cpp" In file included from libs/stacktrace/build/../src/addr2line.cpp:10: In file included from /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/detail/frame_unwind.ipp:15: In file included from /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/frame.hpp:20: In file included from /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/safe_dump_to.hpp:213: /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/detail/collect_unwind.ipp:55:7: error: no member named '_Unwind_Backtrace' in the global namespace ::_Unwind_Backtrace(&boost::stacktrace::detail::unwind_callback, &state); ~~^ 1 error generated. ...skipped <pbin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi>libboost_stacktrace_addr2line.so.1.65.0 for lack of <pbin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi>addr2line.o... ...skipped <p/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/lib>libboost_stacktrace_addr2line.so.1.65.0 for lack of <pbin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi>libboost_stacktrace_addr2line.so.1.65.0... ...skipped <p/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/lib>libboost_stacktrace_addr2line.so for lack of <p/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/lib>libboost_stacktrace_addr2line.so.1.65.0... clang-linux.compile.c++.without-pth bin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi/basic.o "/usr/bin/CC" -c -x c++ -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include -O3 -Wno-inline -Wall -pedantic -pthread -fPIC -m64 -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include -DBOOST_ALL_NO_LIB=1 -DBOOST_STACKTRACE_DYN_LINK=1 -DNDEBUG -I"." -o "bin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi/basic.o" "libs/stacktrace/build/../src/basic.cpp" In file included from libs/stacktrace/build/../src/basic.cpp:9: In file included from /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/detail/frame_unwind.ipp:15: In file included from /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/frame.hpp:20: In file included from /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/safe_dump_to.hpp:213: /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/detail/collect_unwind.ipp:55:7: error: no member named '_Unwind_Backtrace' in the global namespace ::_Unwind_Backtrace(&boost::stacktrace::detail::unwind_callback, &state); ~~^ 1 error generated. ...skipped <pbin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi>libboost_stacktrace_basic.so.1.65.0 for lack of <pbin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi>basic.o... ...skipped <p/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/lib>libboost_stacktrace_basic.so.1.65.0 for lack of <pbin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi>libboost_stacktrace_basic.so.1.65.0... ...skipped <p/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/lib>libboost_stacktrace_basic.so for lack of <p/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/lib>libboost_stacktrace_basic.so.1.65.0... common.mkdir bin.v2/libs/timer

5 5