January 2017 - Boost-users - lists.preview.boost.org

boost 1.63 fails to build with zlib and bzip2 in different directories
by Andrea Bocci 14 Jan '17

14 Jan '17

Hi, I'm trying to build custom binaries for boost 1.63 using zlib and bzip2 from a local installation rather than the system ones, following the instructions at http://www.boost.org/doc/libs/1_63_0/more/getting_started/unix-variants.htm… and http://www.boost.org/doc/libs/1_63_0/libs/iostreams/doc/installation.html but it looks like the build system does not like having the zlib and bzip2 libraries in different folders. Here's what I'm doing to set up the build environment: # create a common directory for zlib and bzip2 mkdir common # build zlib wget http://downloads.sourceforge.net/project/libpng/zlib/1.2.10/zlib-1.2.10.tar… tar xaf zlib-1.2.10.tar.xz cd zlib-1.2.10/ ./configure make test make install prefix=../common cd .. # build bzip2 wget http://www.bzip.org/1.0.6/bzip2-1.0.6.tar.gz tar xaf bzip2-1.0.6.tar.gz cd bzip2-1.0.6/ make -f Makefile-libbz2_so make test make install PREFIX=../common cp -ar libbz2.so.* ../common/lib/ cd .. # build boost wget https://sourceforge.net/projects/boost/files/boost/1.63.0/boost_1_63_0.tar.… tar xaf boost_1_63_0.tar.bz2 cd boost_1_63_0/ mkdir boost-build cd tools/build/ ./bootstrap.sh gcc ./b2 install --prefix=../../boost-build cd ../../ export PATH=$PWD/boost-build/bin:$PATH Now, if I tell boost to pick zlib and bzip2 from the common directory with b2 -q \ -d+2 \ --build-dir=build \ --stage-dir=stage \ --disable-icu \ --without-atomic \ --without-chrono \ --without-container \ --without-context \ --without-coroutine \ --without-exception \ --without-graph \ --without-graph_parallel \ --without-locale \ --without-log \ --without-math \ --without-mpi \ --without-random \ --without-wave \ toolset=gcc \ link=shared \ threading=multi \ variant=release \ cxxflags="-std=c++11 -O2" \ -sBZIP2_INCLUDE=../common/include \ -sBZIP2_LIBPATH=../common/lib \ -sZLIB_INCLUDE=../common/include \ -sZLIB_LIBPATH=../common/lib \ stage it works just fine. However, if I try to build boost using two separate directories for bip2 and zlib, with b2 -q \ -d+2 \ --build-dir=build \ --stage-dir=stage \ --disable-icu \ --without-atomic \ --without-chrono \ --without-container \ --without-context \ --without-coroutine \ --without-exception \ --without-graph \ --without-graph_parallel \ --without-locale \ --without-log \ --without-math \ --without-mpi \ --without-random \ --without-wave \ toolset=gcc \ link=shared \ threading=multi \ variant=release \ cxxflags="-std=c++11 -O2" \ -sBZIP2_INCLUDE=../bzip2-1.0.6 \ -sBZIP2_LIBPATH=../bzip2-1.0.6 \ -sZLIB_INCLUDE=../zlib-1.2.10 \ -sZLIB_LIBPATH=../zlib-1.2.10 \ stage the build fails with 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 : yes - Boost.Config Feature Check: cxx11_auto_declarations : yes - Boost.Config Feature Check: cxx11_constexpr : yes - Boost.Config Feature Check: cxx11_defaulted_functions : yes - Boost.Config Feature Check: cxx11_final : yes - Boost.Config Feature Check: cxx11_hdr_mutex : yes - Boost.Config Feature Check: cxx11_hdr_tuple : yes - Boost.Config Feature Check: cxx11_lambdas : yes - Boost.Config Feature Check: cxx11_noexcept : yes - Boost.Config Feature Check: cxx11_nullptr : yes - Boost.Config Feature Check: cxx11_rvalue_references : yes - Boost.Config Feature Check: cxx11_template_aliases : yes - Boost.Config Feature Check: cxx11_thread_local : yes - Boost.Config Feature Check: cxx11_variadic_templates : yes - zlib : yes error: at /home/fwyzard/src/boost/boost_1_63_0/tools/build/src/kernel/modules.jam:107 error: Name clash for '<pbuild/boost/bin.v2/standalone/ac/gcc-5.4.1/release/threading-multi>main.o' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <dll-path>../zlib-1.2.10 <library-path>../zlib-1.2.10 <xdll-path>../zlib-1.2.10 error: - <dll-path>../bzip2-1.0.6 <library-path>../bzip2-1.0.6 <xdll-path>../bzip2-1.0.6 error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets. I get a similar error if I specify only one of bzip and bzip2. For example Now, if I tell boost to pick zlib and bzip2 from the common directory with b2 -q \ -d+2 \ --build-dir=build \ --stage-dir=stage \ --disable-icu \ --without-atomic \ --without-chrono \ --without-container \ --without-context \ --without-coroutine \ --without-exception \ --without-graph \ --without-graph_parallel \ --without-locale \ --without-log \ --without-math \ --without-mpi \ --without-random \ --without-wave \ toolset=gcc \ link=shared \ threading=multi \ variant=release \ cxxflags="-std=c++11 -O2" \ -sZLIB_INCLUDE=../common/include \ -sZLIB_LIBPATH=../common/lib \ stage results in 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 : yes - Boost.Config Feature Check: cxx11_auto_declarations : yes - Boost.Config Feature Check: cxx11_constexpr : yes - Boost.Config Feature Check: cxx11_defaulted_functions : yes - Boost.Config Feature Check: cxx11_final : yes - Boost.Config Feature Check: cxx11_hdr_mutex : yes - Boost.Config Feature Check: cxx11_hdr_tuple : yes - Boost.Config Feature Check: cxx11_lambdas : yes - Boost.Config Feature Check: cxx11_noexcept : yes - Boost.Config Feature Check: cxx11_nullptr : yes - Boost.Config Feature Check: cxx11_rvalue_references : yes - Boost.Config Feature Check: cxx11_template_aliases : yes - Boost.Config Feature Check: cxx11_thread_local : yes - Boost.Config Feature Check: cxx11_variadic_templates : yes - zlib : yes error: at /home/fwyzard/src/boost/boost_1_63_0/tools/build/src/kernel/modules.jam:107 error: Name clash for '<pbuild/boost/bin.v2/standalone/ac/gcc-5.4.1/release/threading-multi>main.o' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <dll-path>../common/lib <library-path>../common/lib <xdll-path>../common/lib error: - none error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets. As far as I can tell, this used to work with boost 1.57 - I haven't tried any version in between. Anybody has any suggestions ? Thank you, .Andrea -- Strategy is a system of expedients. Generalfeldmarschall Helmuth Karl Bernhard Graf von Moltke

4 11

Boost 1.63.0 with VS 2017 RC
by csiga.biga＠aol.com 09 Jan '17

09 Jan '17

Hi there! There were attempts at building 1.62.0 with the new v141 toolset of MSVC and some success. Did 1.63 make any progress in this regard? I see that the final release still builds libraries labeled v140 even when using a dev cmd prompt with the new compiler. Cheers, Máté

1 0

msvc-14.0 xp support
by Li Sheng 06 Jan '17

06 Jan '17

Hello Boost community, I'm trying to compile boost *1.61.0* with following command on Windows 10 machine: bootstrap.bat b2 headers b2 -a -j9 --stagedir=./stage/boost-xp *toolset=msvc-11.0,msvc-14.0* threading=multi link=static runtime-link=static address-model=64 *define=_USING_V110_SDK71_ define=BOOST_USE_WINAPI_VERSION=0x0501* -d+2 --debug-building As described above, my chosen compilers are MSVC 11 and 14, and I want to enable xp support on produced libraries. Library files compiled by VC11 work fine, but VC14 files are not. Then I added "--debug-building" to see what's actually going on. My console log shows "Command line free features: _USING_V110_SDK71_, BOOST_USE_WINAPI_VERSION=0x0501" when toolset is "msvc-14.0". This does not occur when toolset is "msvc-11.0". After all, can anyone kindly help me with compile boost on msvc-14.0 with xp support? Please forgive me for asking this weird usage. Warmest regards and gratitude, ZD

1 0

[operators] Move Semantics
by Helmut Zeisel 05 Jan '17

05 Jan '17

1 0

[Python] Custom __getattr__ with different CallPolicy for different return values
by H Krishnan 04 Jan '17

04 Jan '17

Hi, I would like to custom __getattr__ for my class such that for some attributes, an internal reference is returned, and for others, a new object is returned. I cannot hardcode the attributes as they are dynamic. I started writing something like: boost::python::object myGetAttr(boost::python::object obj, std::string const& attr) { MyObj* mobj = boost::python::extract<MyObj*>(obj)(); if (attr == "internal_ref") { MyRef* refObj = mobj->getInternalRef(); // how do I return this? } else { MyValueObj obj = mobj->getValueObj(); // how do I return this? } } class_<MyObj, boost::noncopyable> ("MyObj", no_init) .def ("__getattr__", &myGetAttr, ???what_should_I_put_here???) ; However, I am not able to get this to work. Any suggestions? Regards, Krishnan

1 0

How to reuse system_timer of boost::asio with async_wait?
by Bruce 03 Jan '17

03 Jan '17

Hi, I am doing a program that use asio to construct a timer thread. The thread use asio to async_wait many timers. These timers are constructed by boost::asio::system_timer. These timers are mostly designed to fire only once. When they are fired or canceled, I put them to a free queue to reuse. But when I reuse these times, I called expire_from_now() and async_wait() again on the timer, I got the timer fired immediately with error_code set to "ec == boost::asio::error::operation_aborted". And the timer are not fired after like 5 seconds late as I set to expire_from_now(seconds(5)). How to reuse the timer correctly? My codes basically are as follows: m_timer.cancel(); // I tried to cancel the timer first, but no use, I still get the timer fired at once m_timer.expires_from_now(std::chrono::seconds(nInterval)); m_timer.async_wait(boost::bind(&qmInnerTimer::Fire, this, _1)); Thanks. -Bruce

1 0

Boost.Context: SIGSEGV when switch a thread within a catch block
by Александр Пронченков 02 Jan '17

02 Jan '17

Hi, I get SIGSEGV on macOS when I switch an execution_context from a catch block with one thread and than switch back with another thread. Segmentation fault happens in libc++abi.dylib`__cxa_end_catch Does anyone have any ideas, what it could be? Is it legal to switch thread under an excecution_context while it's within a catch block? A minimal example is here: #include <boost/context/all.hpp> #include <future> using Context = boost::context::execution_context<void>; Context Main(Context context) { try { throw std::runtime_error("123"); } catch (const std::exception& ex) { context = context(); } return context(); } int main() { Context context(&Main); context = context(); std::thread([&] { context = context(); }).join(); return 0; } I see the problem on macOS with clang++ but can't reproduce on a linux with g++. $ uname -ap Darwin air.local 16.3.0 Darwin Kernel Version 16.3.0: Thu Nov 17 20:23:58 PST 2016; root:xnu-3789.31.2~1/RELEASE_X86_64 x86_64 i386 $ clang++ --version Apple LLVM version 8.0.0 (clang-800.0.42.1) Target: x86_64-apple-darwin16.3.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin -- Thanks, Alexander Pronchenkov

3 4

[Stacktrace] Review Manager report
by Niall Douglas 02 Jan '17

02 Jan '17

Firstly happy new year to everyone, and many thanks to all those who participated in the peer review of proposed Boost.Stacktrace before Christmas. I received the following formal reviews: 1. Vladimir Batov (YES) 2. Klemens Morgenstern (YES) 3. Andrey Semashev (NO) 4. Nat Goodspeed (YES) 5. Artyom Beilis (NO) 6. Barrett Adair (YES) Extensive comments without a formal acceptance recommendation were also made by: 1. Peter Dimov 2. Edward Diener There was a very noticeable lack of consensus on the strengths and weaknesses of the proposed library which has made summarising all these reviews into a coherent report with concrete conditions for acceptance very difficult. Antony also responded to many of the concerns throughout the review, agreeing with some points, disagreeing with others. I think this lack of consensus stemmed from multiple opinions on what a stacktrace library ought to provide: Minimum viable product: A portable backtrace() and backtrace_symbols() implementation with a C++ STL idiomatic API. The stack backtrace capture implementation must not allocate memory and be "fast". Note that backtrace_symbols() does NOT symbolise into strings containing source file name and line number. It also allocates memory (backtrace_symbols_fd() does not). Opinion 1: Portable serialisation of the stacktrace with instruction pointers converted to offsets into SO/DLL binary paths so a later external process can use those in combination with their debug symbols to retrieve source file names and line numbers. Ideally the serialisation formats supported would include those consumable by well known tooling for this purpose e.g. addr2line or llvm-symbolizer. Opinion 2: That Stacktrace can in process use debug symbols to retrieve source file names and line numbers. This could be implemented by invoking addr2line or equivalent as a child process which has the enormous advantage of being async safe, but has disadvantages in almost every other area. Or it could be implemented by one's own DWARF parser but with the huge caveat that memory could be badly corrupted by now. Opinion 3: That Stacktrace be "async safe" in that backtraces can be safely captured and parsed from a signal handler or SEH/TEH handler callback or point of C++ exception throw. *This implies no memory allocation during the execution of the handler*. >From the reviews, I think there is consensus that the minimum viable product is achieved in Stacktrace though many mentioned that improvements are needed to the documentation and most of the negative feedback was on features not in the minimum viable product described above. I therefore recommend the ACCEPTANCE of proposed Boost.Stacktrace into Boost with the following conditions: 1. That the documentation more clearly set out what Stacktrace does and especially does not do, and that the default facilities provided are those of the Minimum Viable Product described above i.e. no source file nor line number discovery, no external dependencies on libraries not always provided on the target platform, no invocation of child processes, no async safety during stacktrace parsing. Stacktrace ought to be pared back to the minimum viable product featureset with no external dependencies at all. 2. That suitable predefined macros opt in to additional functionality such as serialisation of offset translated backtraces, retrieval of source code path and line number etc. Enabling these may introduce dependencies on third party libraries not always present on a system such as libunwind, or on third party helper utilities such as addr2line. I would recommend that the APIs the use of which are dependent on such third party items are entirely compiled out of Stacktrace when the macro enabling them is not defined. 3. That the documentation describe ONLY the default minimum viable product functionality in its tutorial and quick start. All extra functionality enabled by macros is to be relocated into a separate documentation section away from the main documentation e.g. "Advanced/optional features". 4. That APIs made available only when a given macro has turned them on are documented as such in the API reference docs. I'd like to congratulate Antony on getting yet another library of his into Boost. I hope some of his magic rubs off on me when I bring Outcome to review later this year! Regards, Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 1

[log] disabling logging at compile-time
by Igor R 02 Jan '17

02 Jan '17

Is it possible to completely eliminate the logging code (i.e. the run-time overhead) using some macro? Thanks.

2 1

Problems with nesting boost::container::small_vector and C++98
by Daniel Trstenjak 02 Jan '17

02 Jan '17

Hi, first the used versions: boost 1.63.0 gcc 5.4.0 20160609 Ubuntu 16.04.1 the example I've problems with is: #include <map> #include <boost/container/small_vector.hpp> using boost::container::small_vector; typedef std::pair<int, small_vector<float, 8> > mypair; typedef std::map<int, mypair> mymap; typedef std::map<int, small_vector<mypair, 8> > mymap2; typedef std::map<int, small_vector<small_vector<float, 8>, 8> > mymap3; int main() { mymap m; mypair& sv = m[0]; mymap2 m2; small_vector<mypair, 8>& sv2 = m2[0]; mymap3 m3; small_vector<small_vector<float, 8>, 8>& sv3 = m3[0]; } I can compile it without errors with 'g++ -std=c++11', but without '-std=c++11' I'm getting an error for the 'operator[]' on mymap2: dan@octa ~> g++ -Iboost_1_63_0/ small_vector_test.cpp In file included from boost_1_63_0/boost/container/small_vector.hpp:27:0, from small_vector_test.cpp:2: boost_1_63_0/boost/container/vector.hpp: In instantiation of ‘void boost::container::vector<T, Allocator>::assign(FwdIt, FwdIt, typename boost::move_detail::disable_if_or<void, boost::move_detail::is_same<typename boost::container::container_detail::version<Allocator>::type, boost::move_detail::integral_constant<unsigned int, 0u> >, boost::move_detail::is_convertible<InIt, typename boost::container::allocator_traits<Allocator>::size_type>, boost::container::container_detail::is_input_iterator<FwdIt> >::type*) [with FwdIt = boost::container::container_detail::vec_iterator<std::pair<int, boost::container::small_vector<float, 8ul> >*, true>; T = std::pair<int, boost::container::small_vector<float, 8ul> >; Allocator = boost::container::small_vector_allocator<boost::container::new_allocator<std::pair<int, boost::container::small_vector<float, 8ul> > > >; typename boost::move_detail::disable_if_or<void, boost::move_detail::is_same<typename boost::container::container_detail::version<Allocator>::type, boost::move_detail::integral_constant<unsigned int, 0u> >, boost::move_detail::is_convertible<InIt, typename boost::container::allocator_traits<Allocator>::size_type>, boost::container::container_detail::is_input_iterator<FwdIt> >::type = void]’: boost_1_63_0/boost/container/small_vector.hpp:563:7: required from ‘boost::container::small_vector<T, N, Allocator>::small_vector(const boost::container::small_vector<T, N, Allocator>&) [with T = std::pair<int, boost::container::small_vector<float, 8ul> >; long unsigned int N = 8ul; Allocator = boost::container::new_allocator<std::pair<int, boost::container::small_vector<float, 8ul> > >]’ /usr/include/c++/5/bits/stl_pair.h:113:31: required from ‘std::pair<_T1, _T2>::pair(const _T1&, const _T2&) [with _T1 = const int; _T2 = boost::container::small_vector<std::pair<int, boost::container::small_vector<float, 8ul> >, 8ul>]’ /usr/include/c++/5/bits/stl_map.h:487:23: required from ‘std::map<_Key, _Tp, _Compare, _Alloc>::mapped_type& std::map<_Key, _Tp, _Compare, _Alloc>::operator[](const key_type&) [with _Key = int; _Tp = boost::container::small_vector<std::pair<int, boost::container::small_vector<float, 8ul> >, 8ul>; _Compare = std::less<int>; _Alloc = std::allocator<std::pair<const int, boost::container::small_vector<std::pair<int, boost::container::small_vector<float, 8ul> >, 8ul> > >; std::map<_Key, _Tp, _Compare, _Alloc>::mapped_type = boost::container::small_vector<std::pair<int, boost::container::small_vector<float, 8ul> >, 8ul>; std::map<_Key, _Tp, _Compare, _Alloc>::key_type = int]’ small_vector_test.cpp:18:39: required from here boost_1_63_0/boost/container/vector.hpp:1261:15: error: binding ‘const std::pair<int, boost::container::small_vector<float, 8ul> >’ to reference of type ‘std::pair<int, boost::container::small_vector<float, 8ul> >&’ discards qualifiers *cur = *first; ^ In file included from /usr/include/c++/5/bits/stl_algobase.h:64:0, from /usr/include/c++/5/bits/stl_tree.h:63, from /usr/include/c++/5/map:60, from small_vector_test.cpp:1: /usr/include/c++/5/bits/stl_pair.h:96:12: note: initializing argument 1 of ‘std::pair<int, boost::container::small_vector<float, 8ul> >& std::pair<int, boost::container::small_vector<float, 8ul> >::operator=(std::pair<int, boost::container::small_vector<float, 8ul> >&)’ struct pair ^ Any ideas? Is 'boost:container::small_vector' supposed to work without C++11 support? Thanks! Greetings, Daniel

2 4