- Boost-users - lists.boost.org

Re: [Boost-users] Building Boost 1.63.0 with Oracle Developer Studio 12.5
by Leo Carreon 26 Feb '17

26 Feb '17

These are the issues I have discovered after examining the build log: a.. Error message during configuration check: error: No best alternative for libs/context/build/asm/make_x86_64_sysv_elf_gas.o next alternative: required properties: <threading>multi b.. Warning message during configuration check even after installing developer/icu and library/icu packages: - Boost.Locale needs either iconv or ICU library to be built. c.. Lots of error messages during Boost.Fiber build. d.. Error message during Boost.Python build. I am attaching a copy of the build log for your perusal. I have also adjusted the build command to include “threading=multi”. From: Leo Carreon Sent: Sunday, February 26, 2017 12:40 PM To: Boost Users Mailing List Subject: Building Boost 1.63.0 with Oracle Developer Studio 12.5 Hi, Is building Boost 1.63.0 with Oracle Developer Studio 12.5 supported? I tried building it using the following commands but I get a lot of errors: ./bootstrap.sh --with-toolset=sun ./b2 link=shared runtime-link=shared address-model=64 threading=multi variant=release cxxflags="-std=c++14" linkflags="-std=c++14" FYI, I’m building on Oracle Solaris 11.3 running on a x86-64 virtual machine. Am I missing something? Kind regards, Leo

1 0

Building Boost 1.63.0 with Oracle Developer Studio 12.5
by Leo Carreon 26 Feb '17

26 Feb '17

Hi, Is building Boost 1.63.0 with Oracle Developer Studio 12.5 supported? I tried building it using the following commands but I get a lot of errors: ./bootstrap.sh --with-toolset=sun ./b2 link=shared runtime-link=shared address-model=64 variant=release cxxflags="-std=c++14" linkflags="-std=c++14" FYI, I’m building on Oracle Solaris 11.3 running on a x86-64 virtual machine. Am I missing something? Kind regards, Leo

1 0

[Boost.Build, Coroutine2] /usr/bin/ld: cannot find -lboost_coroutine2
by Mikhail Strelnikov 25 Feb '17

25 Feb '17

Hello. My Jamroot looks like this: local BOOST_ROOT = [ modules.peek : BOOST_ROOT ] ; project my_project : requirements <define>BOOST_ALL_NO_LIB=1 : build-dir bin.v2 ; use-project /boost : $(BOOST_ROOT) ; exe my : my_source.cpp /boost//thread /boost//coroutine2 ; Command line: b2 --build-dir=whatever -sBOOST_ROOT=/path/to/boost_1_63_0 I'm getting the following error: /usr/bin/ld: cannot find -lboost_coroutine2 This happens because a library without sources: https://github.com/boostorg/coroutine2/blob/develop/build/Jamfile.v2#L29 is a pre-built library. Header-only library should use alias - http://www.boost.org/build/doc/html/bbv2/faq/header-only-libraries.html After changing "lib boost_coroutine2..." to "alias boost_coroutine2 ;" I had to add <library>/boost//context to usage-requirements of boost/coroutine2 project. Apparently reference to Context from "requirements" (at line 13) is not enough in this case. Can this be a bug in Boost.Build? But the problem with alias is that "b2 --with-coroutine2" does not build anything at all. My question: is it supported scenario by Boost.Build - header-only library depending on not-header-only library? Bonus question: can those BOOST_DISABLE_ASSERTS be removed from Jamfiles building Context, Coroutine2 and Fiber? Thanks.

1 0

quick question about macro
by Peter Gusev 24 Feb '17

24 Feb '17

hi there! I'm using boost library occasionally and have this simpleton question to ask. i need to debug *boost::asio::io_service* by enabling *BOOST_ASIO_ENABLE_HANDLER_TRACKING* macro. so, do I have to rebuild the library like * ./b2 cxxflags="-DBOOST_ASIO_ENABLE_HANDLER_TRACKING"...* or adding * #define BOOST_ASIO_ENABLE_HANDLER_TRACKING* to my source file is enough? (this doesn't work for me, so i suspect I should go with the first option) thanks, -- Peter Gusev

2 1

[bip] alignment/padding differs
by Jan Boehme 24 Feb '17

24 Feb '17

Hi, I'm using interprocess to share mem between different processes. Unfortunately these processes were built using different compiler version (gcc3, gcc4, gcc5) and we're seeing different alignment or padding dependent on which run-time was in charge of creating the mapped files. Of course we used the same boost version (1.60) while creating the binaries. Obviously ip can't handle these different layouts and mostly runs in indefinite loops while traversing an rb-tree not finding the first shm object. Are there any template parameters that enable the code to be accessed using different run times through forcing the same layout? Thanks a lot, Jan.

2 2

Using Boost 1.63 on Windows with FindBoost.cmake
by csiga.biga＠aol.com 22 Feb '17

22 Feb '17

Does anyone have a working installation of Boost 1.63 on Windows that FindBoost.cmake can be instructed to find? I tried with both a custom build (for MSMPI mostly) that it failed to find the libraries of, and after reading through FindBoost.cmake, I saw it is dominantly tailored towards the prebuilt binaries (at least on Windows), so I grabbed that, I set BOOSTROOT to the installation root, but it still fails to find Boost::chrono I got find_package(Boost 1.63 REQUIRED COMPONENTS chrono) include_directories(${Boost_INCLUDE_DIRS}) in my top-level CMakeLists.txt file, as all of my targets depend on chrono, and after that I use target_link_libraries (${declare_trisycl_test_TARGET} $<$<BOOL:USES_OPENCL>:${OpenCL_LIBRARIES}> $<$<NOT:$<BOOL:WIN32>>:Threads::Threads> Boost::chrono) On the command-line this is what I get at configure time: CMake Error at C:/Kellekek/Kitware/CMake/3.8.0/share/cmake-3.8/Modules/FindBoost.cmake:1812 (message): Unable to find the requested Boost libraries. Boost version: 1.63.0 Boost include path: C:/Kellekek/Boost/1.63.0-prebuilt Could not find the following Boost libraries: boost_chrono Some (but not all) of the required Boost libraries were found. You may need to install these additional Boost libraries. Alternatively, set BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT to the location of Boost. Call Stack (most recent call first): CMakeLists.txt:26 (find_package) As far as FindBoost.cmake goes, it seems to know chrono for 1.63. So how should this work?

2 1

Re: [Boost-users] [Boost.Test] Using intel MKL instead of ACML with the boost testing framework
by anandram sundar 22 Feb '17

22 Feb '17

Sending this again, since I hadnt subscribed before sending this email. One suspicious candidate from further debugging is the results_collector singleton(just because it appears in the stack and because its a singleton) On Tue, Feb 21, 2017 at 2:03 PM, anandram sundar <sundaranandram(a)gmail.com> wrote: > Hi, > I recently wrote some tests using the Boost testing framework and > everything was working fine until I used the intel MKL with my project. As > soon as I started linking these libraries, the tests started failing with a > segmentation fault. This happens after the test execution is done and when > the cleanup is happening. Looking at what valgrind outputs, it seems like > there is some memory being released which is invalid(not sure if it is > because of calling free on already freed memory). This actually happens > even if none of the code depends on the MKL. Just adding them to the linked > libraries is enough to cause this. > > GCC 4.9.3 > Boost ver 1.62 > > *==85160== Invalid read of size 4* > *==85160== at 0x10916C57: std::basic_string<char, > std::char_traits<char>, std::allocator<char> >::~basic_string() (in > /lib/libstdc++.so.6.0.20)* > *==85160== by 0x1104AEBC: __cxa_finalize (in /lib64/libc-2.12.so > <http://libc-2.12.so>)* > *==85160== by 0x41981E2: ??? (in > /lib/libboost_unit_test_framework.so.1.62.0)* > *==85160== by 0x400EC5B: _dl_fini (in /lib64/ld-2.12.so > <http://ld-2.12.so>)* > *==85160== by 0x1104AB21: exit (in /lib64/libc-2.12.so > <http://libc-2.12.so>)* > *==85160== by 0x11033D63: (below main) (in /lib64/libc-2.12.so > <http://libc-2.12.so>)* > *==85160== Address 0x1262fab0 is 16 bytes inside a block of size 30 > free'd* > *==85160== at 0x4C26FD6: operator delete(void*) > (vg_replace_malloc.c:480)* > *==85160== by 0x1104AB21: exit (in /lib64/libc-2.12.so > <http://libc-2.12.so>)* > *==85160== by 0x11033D63: (below main) (in /lib64/libc-2.12.so > <http://libc-2.12.so>)* > > > *==85160== Invalid free() / delete / delete[] / realloc()* > *==85160== at 0x4C26FD6: operator delete(void*) > (vg_replace_malloc.c:480)* > *==85160== by 0x1104AEBC: __cxa_finalize (in /lib64/libc-2.12.so > <http://libc-2.12.so>)* > *==85160== by 0x41981E2: ??? (in > /lib/libboost_unit_test_framework.so.1.62.0)* > *==85160== by 0x400EC5B: _dl_fini (in /lib64/ld-2.12.so > <http://ld-2.12.so>)* > *==85160== by 0x1104AB21: exit (in /lib64/libc-2.12.so > <http://libc-2.12.so>)* > *==85160== by 0x11033D63: (below main) (in /lib64/libc-2.12.so > <http://libc-2.12.so>)* > *==85160== Address 0x1262faa0 is 0 bytes inside a block of size 30 free'd* > *==85160== at 0x4C26FD6: operator delete(void*) > (vg_replace_malloc.c:480)* > *==85160== by 0x1104AB21: exit (in /lib64/libc-2.12.so > <http://libc-2.12.so>)* > *==85160== by 0x11033D63: (below main) (in /lib64/libc-2.12.so > <http://libc-2.12.so>)* > > > I am not sure why this is happening. Are there any known compatibility > issues between MKL and Boost testing framework. I was using ACML before > this and the tests were working fine with them. > > > Thanks, > Anand >

1 0

[iostreams] filtering streams in a chain are continually writing the same bytes
by Andrew Ames 21 Feb '17

21 Feb '17

Perhaps someone can clarify that my use of multichar_output_filter is valid. When I debug this, even though my write method is returning 4 bytes for every write, the caller of my output filter keeps providing me the same four bytes after the first sequence of 4 bytes. This is boot version 1.62. Here is compiling code that illustrates: class fixed_size_output_filter : public boost::iostreams::multichar_output_filter { public: fixed_size_output_filter(std::streamsize size = 4) : mSize(size) {} template<typename Sink> std::streamsize write(Sink &sink, const char *s, std::streamsize n) { std::streamsize bytesAttempted = std::min(mSize, n); std::streamsize bytesActual = boost::iostreams::write(sink, s, bytesAttempted); return bytesActual; } private: std::streamsize mSize; }; BOOST_AUTO_TEST_CASE(FixedSizeOutputFilter) { #define BYTES 500 char sink_buffer[BYTES]; array_sink array_sink(sink_buffer, sizeof(sink_buffer)); std::streampos os_pos; { filtering_ostream os; os.push(fixed_size_output_filter()); os.push(array_sink); char buffer[BYTES]; for(char i = 0; i < sizeof(buffer); i++) buffer[i] = i; os.write(buffer, sizeof(buffer)); } for(char i = 0; i < sizeof(sink_buffer); i++) BOOST_CHECK(i == sink_buffer[i]); } The actual bytes that end up in the sink_buffer are as follows: 0, 1, 2, 3, 4, 5, 6, 7, 4, 5, 6, 7, 4, 5, 6, 7, 4, 5, 6, 7, ....uninitialized bytes follow through the rest of the buffer. It would appear that the indirect_streambuf in use by the filter chain is incorrectly flushing the bytes. Is my understanding of the library flawed? Does this appear to be a bug? Any help is greatly appreciated. -- Andrew Ames aames(a)tanzle.com

1 1

[thread] Ambiguity in variadic wait_for_all
by Gavin Lambert 18 Feb '17

18 Feb '17

A colleague recently ran into an interesting issue when upgrading some working code from Boost 1.55 to 1.60/1.63 (and from C++03 to C++11). The exact details are unimportant, but it was trying to get the address of boost::wait_for_all(Iterator, Iterator), for use in a Boost.Bind call. In 1.55, this worked fine, although of course it had to supply template parameters that proved the parameters were not futures (thus causing enable_if<is_future_type<F1>> to fail, disabling the two-future-args overload of the function. In 1.60/1.63, the variadic method is encountered instead, which lacks any enable_if condition and thus the ambiguity between the two remains and the compiler errors out. (When calling it directly, the variadic one manages to get disabled as long as the iterator type lacks a wait() method, but this doesn't apply when just getting the method address, as it's not part of the signature.) Should the variadic form also have enable_if? Or is this considered user error for trying to use Bind in a variadic-compatible compiler instead of using a lambda?

2 3

Scheduled Outage : Web sites / Trac
by Michael Caisse 18 Feb '17

18 Feb '17

We are planning the final move of services from IU this week. Expect service outages for all web sites including Trac on 17-February-2017 between 16:00 UTC - 00:00 UTC. The mail lists will continue to operate during this time; however, all other sub-domains for boost.org will be affected. Sync'ing bandwidth with IU has been low recently and has caused us to increase the outage window. We will notify these lists when services are available again. Thank you for your patience during the move. -- Michael Caisse Ciere Consulting ciere.com

1 1