- Boost - lists.preview.boost.org

Boost 1.54 build integration errors in VS2017
by nunna, sarath babu (GE Healthcare) 26 Jun '19

26 Jun '19

HI, I am getting below error when I tried to integrate boost 1.54 version into our project using VS2017. error C3861: 'assert_arg': identifier not found error C2039: 'assert_arg': is not a member of 'boost::mpl' I am not able to fix this error. Hence, Please provide me help to get rid of this error. Thanks, Sarath.

2 1

IP TCP connections asio::ip::tcp::socket
by JH 25 Jun '19

25 Jun '19

Hi, I am running an application using boost ASIO IP/TCP socket to connect Internet. I have two network interfaces, when one is down, it switches to another one, in my application

1 0

[boost-ci] Added support for building big-endian on Travis CI
by James E. King III 24 Jun '19

24 Jun '19

You can now run a big-endian build job on Travis CI through some docker magic. I had an endian bug in some relatively new code in Boost.UUID (in the MD5 hasher) that required a big endian environment to build in and test with, so I had to solve this impediment. The Boost Docker Development Environment (BDDE) was taught how to build and run multiarch images. At this point I'd like to consider having BDDE move into boostorg alongside boost-ci. It provides an easy way to hop into or run boost builds inside docker containers. One of the examples is to run a predef unit test in the arm64 or ppc64 containers and see how predef defines the macros. Following that, Boost-CI was taught how to use BDDE under Travis CI to run a build in one of the containers. When running the red-ppc64 image expect a slowdown in the 10x to 20x range. If you are concerned about build time on Travis CI (maximum length 50 minutes), I would recommend running a subset of tests. Even building b2 (bootstrap) takes more than a minute. Building Boost.UUID with tests takes about 25 minutes (this includes building some of Boost.Serialization). You can also use BDDE directly to build the same way on a docker-enabled development system. I wasn't able to run gdb in this environment when the architecture was ppc64, but I could build and run tests. gdb works on the x86_64 docker container. Boost-CI: https://github.com/boostorg/boost-ci BDDE: https://github.com/jeking3/bdde Example PR that enables it on Travis CI: https://github.com/boostorg/uuid/pull/109 Enjoy, - Jim

1 0

Serialization Issue found in 1.69 and 1.70 of boost libraries
by nunna, sarath babu (GE Healthcare) 24 Jun '19

24 Jun '19

Hello, We use boost libraries in our project. We had no issues found in 1.47 version in our product.(In Windows 7) But we wanted to upgrade to latest version into Windows 10 environment. We have got issues with serialization. Please let us know in which version you have introduced serialization above than 1.47 version? So that we will take one version below than that or let us know whether have to include/modify anything to adopt latest 1.69 or 1.7 version of boost. Your response will be a great help to us. Thanks, Sarath.

2 1

[build] Option to have b2 show stdout from target run?
by James E. King III 24 Jun '19

24 Jun '19

Currently b2 only shows output when a test fails unexpectedly. If I want to build and run a test and see the stdout from the test all in one command, is there a b2 option that would do that? For example, the output from predef's "info_as_cpp" test is useful, and I'd like to have a single command line that builds it, runs it, and shows stdout. I don't see a way to do this with b2, even with the -d+n flags. I can do it this way, but it's fragile: $(b2 -a -ox info_as_cpp | grep 'gcc.link' | cut -d' ' -f2) - Jim

3 2

B2 release 4.0.0
by Rene Rivera 24 Jun '19

24 Jun '19

After even more years of development the landscape of build systems has changed considerably, and so has the landscape of compilers. This version marks the start of B2 transitioning to a C++ implementation. Initially this means that the engine will be compiled as C++ source but that source is still the base C implementation. Over time it will transform to a C++ code base in both the engine and build system. Some changes in this start: - Requires C++ 11 to build engine. - Simplified build scripts to make it easier to maintain. - Building with C++ optimizations gives an immediate performance improvement. *Other changes in this release:* - Add support for using prebuilt OpenSSL. -- *Damian Jarek* - Define the riscv architecture feature. -- *Andreas Schwab* - Add ARM64 as a valid architecture for MSVC. -- *Marc Sweetgall* - Set coverage flags, from coverage feature, for gcc and clang. -- *Damian Jarek* - Add s390x CPU and support in gcc/clang. -- *Neale Ferguson* - Support importing pkg-config packages. -- *Dmitry Arkhipov* - Support for leak sanitizer. -- *Damian Jarek* - Fix missing /manifest option in clang-win to fix admin elevation for exes - with "update" in the name. -- *Peter Dimov* - Add freertos to os feature. -- *tee3* - Default parallel jobs (-jX) to the available CPU threads. -- *Rene Rivera* - Simpler coverage feature. -- *Hans Dembinski* - Better stacks for sanitizers. -- *James E. King III* *WARNING*: The default number of parallel jobs has changed in this release from "1" to the number of cores. There are circumstances when that default can be larger than the allocated cpu resources, for instance in some virtualized container installs. *Continuously tested on:* - Linux Clang 3.5, 3.6, 3.7, 3.8, 3.9, 4, 5, 6, 7, 8 - Linux GCC 4.7, 4.8, 4.9, 5, 6, 7, 8, 9 - macOS Xcode 8.3.3, 9.0, 9.0.1, 9.1, 9.2, 9.3, 9.3.1, 9.4, 9.4.1, 10.0, 10.1, 10.2, 10.2.1 - Windows MinGW 8.1.0 - Windows VS 2013, 2015, 2017, 2019 Documentation and more at <https://boostorg.github.io/build/> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

2 2

Re: [boost] [Boost-testing] Test Failures on develop
by Tom Kent 24 Jun '19

24 Jun '19

On Fri, Jun 21, 2019 at 5:11 AM Tom Kent <lists(a)teeks99.com> wrote: > > > On Thu, Jun 20, 2019, 10:35 PM Rene Rivera <grafikrobot(a)gmail.com> wrote: > >> On Thu, Jun 20, 2019 at 10:28 PM Tom Kent <lists(a)teeks99.com> wrote: >> >>> >>> On Thu, Jun 20, 2019 at 7:15 AM Rene Rivera <grafikrobot(a)gmail.com> >>> wrote: >>> >>>> Since it's not due to the b2 -j change.. >>>> >>>> On Fri, Jun 14, 2019 at 8:25 AM Tom Kent via Boost-Testing < >>>> boost-testing(a)lists.boost.org> wrote: >>>> >>>>> For the last few days (Since June 4?) I've been having problems with >>>>> all my linux tests running against the develop branch. >>>>> >>>>> GCC ends with this: >>>>> >>>>> gcc.compile.c++ ../../bin/common/build/gcc-8/release/process_jam_log.o >>>>> >>>>> "g++-8" -fPIC -O3 -finline-functions -Wno-inline -Wall >>>>> -DBOOST_ALL_NO_LIB=1 -DNDEBUG -D_CRT_SECURE_NO_WARNINGS - >>>>> I"/var/boost/run/boost_root" -c -o >>>>> "../../bin/common/build/gcc-8/release/process_jam_log.o" >>>>> "../../common/build/../src/p >>>>> rocess_jam_log.cpp" >>>>> >>>>> ../../common/build/../src/process_jam_log.cpp: In function >>>>> 'std::__cxx11::string {anonymous}::revision(const string&)': >>>>> ../../common/build/../src/process_jam_log.cpp:359:16: warning: >>>>> ignoring return value of 'int system(const char*)', decla >>>>> red with attribute warn_unused_result [-Wunused-result] >>>>> std::system("git rev-parse --short=6 HEAD >.short-sha"); >>>>> ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> ...skipped <p../../bin/testing/build/gcc-8/release>process_jam_log for >>>>> lack of <p/var/boost/run/boost_root/bin.v2/libs/f >>>>> ilesystem/build/gcc-8/release/link-static/visibility-hidden>libboost_filesystem.a... >>>>> >>>>> >>>> >>>> I guess you'd need to find out what it says for trying to build >>>> filesystem lib. >>>> >>> >>> Here's what I'm seeing with the filesystem error: >>> >>> ln -f -s >>> "../../libs/detail/include/boost/detail/has_default_constructor.hpp" >>> "../../../boost_root/boost/detail/has_ >>> default_constructor.hpp" >>> >>> gcc.compile.c++ >>> /var/boost/run/boost_root/bin.v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/path_traits.o >>> >>> "g++-8" -fvisibility-inlines-hidden -m64 -O3 -finline-functions >>> -Wno-inline -Wall -fvisibility=hidden -DBOOST_ALL >>> _NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DNDEBUG >>> -I"/var/boost/run/boost_root" -c -o "/var/boost/run/boost_root/bin. >>> v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/path_traits.o" >>> "/var/boost/run/boost_root/libs/file >>> system/src/path_traits.cpp" >>> >>> /var/boost/run/boost_root/libs/filesystem/src/path_traits.cpp:20:10: >>> fatal error: boost/filesystem/config.hpp: No such f >>> ile or directory >>> #include <boost/filesystem/config.hpp> >>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> compilation terminated. >>> ...failed gcc.compile.c++ >>> /var/boost/run/boost_root/bin.v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/path_traits.o... >>> gcc.compile.c++ >>> /var/boost/run/boost_root/bin.v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/portability.o >>> >>> "g++-8" -fvisibility-inlines-hidden -m64 -O3 -finline-functions >>> -Wno-inline -Wall -fvisibility=hidden -DBOOST_ALL >>> _NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DNDEBUG >>> -I"/var/boost/run/boost_root" -c -o "/var/boost/run/boost_root/bin. >>> v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/portability.o" >>> "/var/boost/run/boost_root/libs/file >>> system/src/portability.cpp" >>> >>> /var/boost/run/boost_root/libs/filesystem/src/portability.cpp:20:10: >>> fatal error: boost/filesystem/config.hpp: No such f >>> ile or directory >>> #include <boost/filesystem/config.hpp> >>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> compilation terminated. >>> ...failed gcc.compile.c++ >>> /var/boost/run/boost_root/bin.v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/portability.o... >>> >>> >>> And several more like that. >>> >>> However, I'm also suspicious of the timing with the processor change. >>> >>> Looking back at the last successful builds of develop on linux. I have a >>> few from linux/x86_64/docker machines. The last one I saw was building with >>> gcc-8 on June 4 around 6:30am CDT. There should have been a successful >>> clang run about 5hrs after that (11:30am CDT), and another successful gcc >>> around 10hrs after the last one that was actually successful (4:30pm CDT). >>> >>> This seems like it would correspond to the change to build here: >>> >>> https://github.com/boostorg/build/commit/451059949d92b52b21f802562a50587f1e… >>> >>> The other failure I started seeing was only my linux/arm64 machine. This >>> doesn't run docker, so might not be affected in the same way. The last >>> successful run on there was at 4:50pm CDT on June 4...but it typically >>> takes around 9hrs to run so it probably got the pre 451059949 commit. >>> However here I can't rule out that it was impacted by a8ab76ef973. >>> >>> I'm going to try to standup some normal VMs soon and run on them to see >>> if they are affected in the same way. It would also be nice if we could try >>> backing out the usage of _SC_NPROCESSORS_ONLN and see if that fixes things, >>> is that feasible to try for a couple days? >>> >> >> Again.. It's not a b2 issue. Specifying the "-jX" option entirely >> obviates the changed code. It's almost certainly something else. Places to >> look would be in the filesystem lib, or the root "boost" project for >> changes. >> > > Looking at regression.py it looks like the command that builds > process_jam_log doesn't use the bjam options. Can you verify if this > is/isn't the case? > > Tom > Somewhere between 9:57am and 12:02pm CDT today this bug migrated to master. It can trivially be re-produced. On a bare linux vm...Azure F8s_v2, Ubuntu 18.04, standard SSD. $ sudo apt update && sudo apt install build-essential gcc-8 g++-8 python python3 git wget ... $ wget https://raw.githubusercontent.com/boostorg/regression/develop/testing/src/r… $ echo using gcc : 8 : g++-8 : \; > ~/user-config.jam $ python run.py --runner=teeks99-test01 --toolsets=gcc-8 --tag=develop --bjam-options="-j8 address-model=64" ...fails with the above errors. You can also do the same thing to reproduce in a docker image (ubuntu:bionic). --bjam-options of -j1 -j8 and absent all fail the same. This does not correspond to any changes between the filesystem library that indicates the error. But it *does* correspond exactly with the release of the new B2. https://github.com/boostorg/build/commit/04efaac148671479b514db882b1c520dca… There have been no successful regression tests by any linux runners since that time. Tom

2 2

Release tags request..
by Rene Rivera 24 Jun '19

24 Jun '19

B2 is doing it's own "out of band" (aka independent) releases. In order to avoid confusion.. Can the Boost release process please avoid tagging the build subrepo with the Boost release tags from now on? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

4 8

[boost-users] [compiler] Boost VC++ 14.2 test compiler
by Alex J 23 Jun '19

23 Jun '19

Hi, Does anybody know when VC++ 14.2 will be added as a 'primary compiler tested' ?. At the moment there is only VC++ 14.1. Thanks

1 0

Travis CI again.
by John Maddock 23 Jun '19

23 Jun '19

Sorry, but I need help, and simply can not see what's going wrong with: https://github.com/boostorg/config/pull/286. Travis doesn't even seem to be building the same code as has been pushed? And until I can get CI functioning again here, and in other libraries, nothing gets merged to master :( Sorry if I'm being dense, and thanks in advance, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

3 4