- Boost - lists.boost.org

[1.67] Missing include in Boost.Graph
by Denis Davydov 03 Apr '18

03 Apr '18

Dear all, 1.67.0.beta1 has a regression of missing include in Boost.Graph which prevents deal.II https://www.dealii.org <https://www.dealii.org/> project from building. Even though the file was not modified since 2015, it’s a regression as we have not had this issue with previous versions of boost. The one-liner fix is here https://github.com/boostorg/graph/pull/104 <https://github.com/boostorg/graph/pull/104> I would appreciate if you could merge it prior to 1.67.0 release. ps. https://github.com/boostorg/graph/pull/101 <https://github.com/boostorg/graph/pull/101> is a better way to fix it but as suggested in https://svn.boost.org/trac10/ticket/13505#comment:4 <https://svn.boost.org/trac10/ticket/13505#comment:4> this might not get merged into 1.67.0, which would be pity. Regards, Denis

3 2

Build breaking changes
by Antony Polukhin 03 Apr '18

03 Apr '18

Hello, I've just noted that building Boost from master stopped working: [00:16:51] b2.exe -j4 toolset=gcc --layout=system variant=release architecture=x86 link=static --with-program_options --with-filesystem --with-system --with-test --with-atomic --with-thread --with-timer --with-date_time --with-chrono --with-regex --with-random --with-context stage [00:16:52] Performing configuration checks [00:16:52] [00:16:52] - default address-model : 32-bit [00:16:53] - default architecture : x86 [00:16:53] - symlinks supported : yes (cached) [00:16:54] - C++11 mutex : yes [00:16:55] - has_icu builds : no [00:16:55] - BOOST_COMP_GNUC >= 4.3.0 : yes [00:16:55] - C++11 mutex : no [00:16:56] - has_icu builds : no [00:16:56] - BOOST_COMP_GNUC >= 4.3.0 : no [00:16:56] error: Name clash for '<pstage\lib>libboost_atomic.a' [00:16:56] error: [00:16:56] error: Tried to build the target twice, with property sets having [00:16:56] error: these incompatible properties: [00:16:56] error: [00:16:56] error: - <address-model>64 [00:16:56] error: - <address-model>32 [00:16:56] error: [00:16:56] error: Please make sure to have consistent requirements for these [00:16:56] error: properties everywhere in your project, especially for install [00:16:56] error: targets. [00:16:56] [00:16:56] Command exited with code 1 Previously this build command worked fine. Full log available at https://ci.appveyor.com/project/apolukhin/boost-cookbook/branch/second_edit… Is this an intended breaking change?

12 21

Debate until Decision
by James E. King, III 03 Apr '18

03 Apr '18

I'm going to float some thoughts about how the group makes decisions below. I'm not suggesting a specific course of action, but I would like people to think about how these ideas can be used to improve Boost development. Recent discussions about default address-model, and past discussions about issues like cmake and CI build improvements (like whether or not to purchase more build slaves from travis or appveyor), and topics about legal use of code snippets leads me to the following conclusion: 1. We are geographically, culturally, and vertically distributed and have highly varying viewpoints. 2. We are all very good at expressing our viewpoint about various topics. 3. We collectively need to improve our skill at coming to a group decision and moving forward. Folks generally have individual control over their respective maintained repositories in the current structure. There are many topics that generally affect all of the repositories, such as the ones I mentioned previously, that affect all of us. At my most recent startup company we implemented an effective "Debate until Decision" mechanism by which: 1. The issue is discussed. (We do this well) 2. A decision is made and implemented (We do not seem to do this well): Not everyone will be happy with the outcome. Folks should not attempt to undermine the outcome after decision. The issue can be raised again if new information is brought to light. How is a decision made? Typically in a meeting where people vote face-to-face. For a group like this, voting would be done online with a time limit. Who can vote? That's a good question. In this environment it may fall to the group of folks who are maintainers of an affected repository. I don't necessarily have a good answer for that, as I am relatively new to the group. Some folks have been here for 10+ years and may feel differently that seniority should have a say. I don't know. What are the benefits of this? Simply: *Things get done.* Look at the cmake discussion, or the CI build job discussion, or the current address-model discussion. These need to be finished, agreed to, and implemented (or not), and everyone moves forward. The Apache Software Foundation maintains a fairly well documented structure for each project, with a project management committee consisting of a chair and members who have equal voting rights, however said group's primary function is to identify and grow the team of developers who have commit privileges. The committers as a whole vote on issues that are project-wide, like "should we split into multiple repositories", or "should we move to another source code control environment"? This mechanism could also be applied to how folks are brought into maintainer status for a repository, or how a library enters the CMT. If you look at the bug backlog in trac for some one the libraries, it's pretty clear that they are not properly maintained. The issue may be discussed, but then dropped and forgotten, and no action is taken to remedy it. When repositories have pull requests open for years, or a backlog of 100 defects going back 10 years, there's a very unhealthy problem for that project that needs to be addressed. It may be a similar structure that will work well here. Folks may disagree. This will be debated, certainly, as folks probably have varying opinions about how much structure is needed or desired. I simply hope this leads to an effective discussion about how this group identifies deficiencies, solves them, and moves forward. Any group large or small can benefit from examination and improvement of processes, including ours. Thanks, Jim

5 5

[ineterprocess] managed mapped file - recovery from process failure
by Assaf Ben-amitai 02 Apr '18

02 Apr '18

Hi, I have noticed that if a process is killed while it's allocating memory from a managed file, later loading of the managed file may segfault (even in read-only mode). A. What is the expected behaviour in this case? B. Should such a segfault be considered as a bug or is it the case that the user is not supposed to use the managed file after process failure? C. If unsupported, any pointers on efforts to improve this? Thx, Assaf

2 1

[cmake] Where to discuss CMake in Boost?
by Mateusz Loskot 02 Apr '18

02 Apr '18

Hi, TL;TR: Which is the right mailing list to discuss CMake in Boost? Numerous CMake discussions happened here lately which, I think, were mostly about the grand Boost vs CMake strategy, politics. The boost-cmake ml has been quiet for years now, according to its archives. https://lists.boost.org/mailman/listinfo.cgi/boost-cmake Whereas, there has been lots of activity in development of CMake for various aspects: to use CMake inside Boost. to use CMake to build Boost, etc. That is https://github.com/boost-cmake where, in particular, I'm interested in https://github.com/boost-cmake/bcm Where can I ask *technical* questions about those to avoid polluting wrong list? Best regards. -- Mateusz Loskot, http://mateusz.loskot.net

5 10

[gil] Locator bug in MSVC release builds
by Christian Henning 31 Mar '18

31 Mar '18

Hi all, there is this nagging bug (#49) with boost::gil which I have a hard time figuring out. Please consider the following code: #define _CRT_SECURE_NO_WARNINGS 1 #include <boost/gil/gil_all.hpp> #include <boost/gil/extension/io/bmp_all.hpp> using namespace boost::gil; int main() { using ref_t = const bit_aligned_pixel_reference<boost::uint8_t, boost::mpl::vector3_c<int, 1, 2, 1>, bgr_layout_t, true>; using ptr_t = bit_aligned_pixel_iterator<ref_t>; using pixel_t = std::iterator_traits<ptr_t>::value_type; using bgr121_image_t = image<ref_t, false>; ////////////////////// // works ////////////////////// { bgr121_image_t a(10, 10); fill_pixels(view(a), pixel_t(0, 0, 1)); auto loc = view(a).xy_at(0, 0); for (int y = 0; y < view(a).height(); ++y) { *loc = pixel_t(1, 0, 0); ++loc.x(); ++loc.y(); } auto v = color_converted_view<rgb8_pixel_t>(view(a)); write_view("a.bmp", v, bmp_tag()); } ////////////////////// // doesn't work ////////////////////// { bgr121_image_t b(10, 10); fill_pixels(view(b), pixel_t(0, 0, 1)); auto loc = view(b).xy_at(0, view(b).height() - 1); for (int y = 0; y < view(b).height(); ++y) { *loc = pixel_t(1, 0, 0); ++loc.x(); --loc.y(); } auto v = color_converted_view<rgb8_pixel_t>(view(b)); write_view("b.bmp", v, bmp_tag()); } } When running with VS 2017 all is working in Debug but with Release the second image is incorrect. The bug should be in the locator code. Anyone has an idea what is going wrong or what else I should try? Thanks, Christian

2 3

[boost.test] merging minor changes to master
by Raffi Enficiaud 31 Mar '18

31 Mar '18

Hi list, I merged a very minor commit that will make MinGW people happy. Rev of Boost.test on master is now 413b2f660118060db732dbf38a2bdffb527395e3 . Since Beta1: * doc updates * small bugfix PR 134 * include all lower case on windows for MinGW. PR 136 I would be grateful to the release managers if those changes go to the final 1.67 release. Thanks, Raffi

1 0

Maintenance of boostorg on AppVeyor
by Mateusz Loskot 30 Mar '18

30 Mar '18

Hi, I found [1] there is boostorg account on AppVeyor https://ci.appveyor.com/project/boostorg/boost/ There seem to be no sites/URLs per GitHub repo, eg. https://ci.appveyor.com/project/boostorg/hana https://ci.appveyor.com/project/boostorg/gil etc. I'm unclear how this is setup, but boostorg/boost seems to be a sink for all boostorg repos on GitHub. What is the purpose of this AppVeyor boostorg account? Can library maintainers have access to this account and use to build their library repo? If yes, where can I request to set-up AppVeyor roles [2] for Boost.GIL maintainers, so they can cancel/re-run builds? Or, is it that typically maintainers are supposed to create sparate account for builds a library, eg. ci.appveyor.com/project/mloskot/gil Isn't such duplication of builds a waste of resources? [1] https://lists.boost.org/Archives/boost/2015/06/223325.php [2] https://www.appveyor.com/docs/team-setup/#github-integration Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Failing to use b2/bjam including libraries with Clang
by Paul A. Bristow 30 Mar '18

30 Mar '18

I am still failing to get Clang on Windows 10 to work with b2/bjam *linking to libraries*. I have a few simple test cases, using Boost.System to display an error code ,using Boost.Test for a 'hello World" use of Boost.Test, and a simple regex example1 linking to Boost.Regex library. All links to libraries are static (to avoid reported problems with DLL and Clang). I have tried to use the LLD linker http://releases.llvm.org/6.0.0/tools/lld/docs/ReleaseNotes.html as some have recommended this, but not successfully with libraries, so far. Things that DO work OK with Clang 6.0.0 are 1 Visual Studio IDE (using Boost prebuilt libraries) Platform Toolset = llvm-2014 and MS linker only. 2 Codeblocks IDE (mingw64 on windows 10) (using normal Boost prebuilt libraries as part of the normal install) and clang++.exe. (But NOT when using the LTO lld.exe linker getting error: Expected a single module ???- but I am not trying to use C++ modules!). 3 Using b2/bjam to run a *single* exe (no libraries). jamfile is just [ run hello_boost.cpp ] with >b2 toolset=gcc-7.2.0,msvc-14.1,clang-6.0.0 4 Using all examples in jamfile b2/bjam with libraries with toolset=gcc-7.2.0,msvc-14.1 (so I am confident that it is not a problem with the C++ or the jamfile). What *doesn't work* is b2/bjam using a library with toolset=clang-6.0.0, neither using clang++ linker nor using LTO llvm-lld.exe. And since I want to write b2 -a -j6 --debug-configuration -d2 toolset=msvc-14.1,gcc-7.2.0,clang-6.0.0 address-model=64 > my.log this is most disappointing :-( My user-config.jam contains using clang : # Version. 6.0.0 : # Location of Clang compiler .exe file(s). "C:/LLVM/clang-600/LLVM/bin/clang++.exe" : # Options. <compileflags>-v <compileflags>-m64 <compileflags>-fmsc-version=1900 <compileflags>--target=i686-pc-windows-msvc <define>_CRT_SECURE_NO_DEPRECATE <define>_CRT_SECURE_NO_WARNINGS <cxxflags>-std=c++17 <cxxflags>-flto=thin <<<<<<< if trying to use LTO lld linker <cxxflags>-Wno-deprecated <cxxflags>-Wno-deprecated-declarations <linkflags>-v <linkflags>-fuse-ld=lld <<<<<<< if trying to use LTO lld linker <linkflags>-flto=thin <<<<<<< if trying to use LTO lld linker <linkflags>--verbose <linkflags>-m64 <linkflags>--target=i686-pc-windows-msvc <linkflags>-lmsvcrt The Boost.Test and Boost.System libraries are built as expected (for Clang) at "..\..\..\bin.v2\libs\system\build\clang-gnu-linux-6.0.0\release\address-model-64\link-static\threadapi-win32\libboost_system-clang6 0-x64-1_66.lib" my jamfile contains lines like [ run hello_boost_system.cpp ../../system/build//boost_system/<link>static ] [ run hello_boost_test.cpp : : : <library>/boost/test//boost_unit_test_framework/<link>static ] After trying a bewildering array of linkers, and many options, I finally always end up with a series of link failures with errors either like error: lto.tmp: undefined symbol: ? system_category@system@boost@@YAAEBVerror_category@12@XZ or a missing entry point: LINK : fatal error LNK1561: entry point must be defined (This appears to be a message from MSVC, not the lld linker?) clang-linux.link ..\..\..\bin.v2\libs\hello_boost_test\test\hello_boost_system.test\clang-gnu-linux-6.0.0\release\address-model-64\threadapi-win32\he llo_boost_system.exe "C:/LLVM/clang-600/LLVM/bin/clang++.exe" -o "..\..\..\bin.v2\libs\hello_boost_test\test\hello_boost_system.test\clang-gnu-linux-6.0.0\release\address-model-64\threadapi-win32\h ello_boost_system.exe" -Wl,--start-group "..\..\..\bin.v2\libs\hello_boost_test\test\hello_boost_system.test\clang-gnu-linux-6.0.0\release\address-model-64\threadapi-win32\h ello_boost_system.obj" "..\..\..\bin.v2\libs\system\build\clang-gnu-linux-6.0.0\release\address-model-64\link-static\threadapi-win32\libboost_system-clang6 0-x64-1_66.lib" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -v -fuse-ld=lld -flto=thin --verbose -m64 --target=i686-pc-windows-msvc -lmsvcrt -m64 clang version 6.0.0 (tags/RELEASE_600/final) Target: x86_64-pc-windows-msvc Thread model: posix InstalledDir: C:\LLVM\clang-600\LLVM\bin "C:\\LLVM\\clang-600\\LLVM\\bin\\lld-link" "-out:..\\..\\..\\bin.v2\\libs\\hello_boost_test\\test\\hello_boost_system.test\\clang-gnu-linux-6.0.0\\release\\address-model-64\\t hreadapi-win32\\hello_boost_system.exe" -defaultlib:libcmt "-libpath:C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Professional\\VC\\Tools\\MSVC\\14.13.26128\\lib\\x64" "-libpath:C:\\Program Files (x86)\\Windows Kits\\10\\Lib\\10.0.16299.0\\ucrt\\x64" "-libpath:C:\\Program Files (x86)\\Windows Kits\\10\\Lib\\10.0.16299.0\\um\\x64" -nologo --start-group "..\\..\\..\\bin.v2\\libs\\hello_boost_test\\test\\hello_boost_system.test\\clang-gnu-linux-6.0.0\\release\\address-model-64\\thread api-win32\\hello_boost_system.obj" "..\\..\\..\\bin.v2\\libs\\system\\build\\clang-gnu-linux-6.0.0\\release\\address-model-64\\link-static\\threadapi-win32\\libboost_s ystem-clang60-x64-1_66.lib" -Bstatic -Bdynamic --end-group msvcrt.lib C:\LLVM\clang-600\LLVM\bin\lld-link: warning: ignoring unknown argument: --start-group C:\LLVM\clang-600\LLVM\bin\lld-link: warning: ignoring unknown argument: -Bstatic C:\LLVM\clang-600\LLVM\bin\lld-link: warning: ignoring unknown argument: -Bdynamic C:\LLVM\clang-600\LLVM\bin\lld-link: warning: ignoring unknown argument: --end-group C:\LLVM\clang-600\LLVM\bin\lld-link: error: lto.tmp: undefined symbol: ?system_category@system@boost@@YAAEBVerror_category@12@XZ C:\LLVM\clang-600\LLVM\bin\lld-link: error: lto.tmp: undefined symbol: ?generic_category@system@boost@@YAAEBVerror_category@12@XZ clang++.exe: error: linker command failed with exit code 1 (use -v to see invocation) Which seems to indicate some link problem finding error_category (error_category is found OK with GCC or MSVC)? and for a simple use of Boost.Test library clang version 6.0.0 (tags/RELEASE_600/final) Target: x86_64-pc-windows-msvc Thread model: posix InstalledDir: C:\LLVM\clang-600\LLVM\bin "C:\\LLVM\\clang-600\\LLVM\\bin\\lld-link" "-out:..\\..\\..\\bin.v2\\libs\\hello_boost_test\\test\\hello_boost_test.test\\clang-gnu-linux-6.0.0\\release\\address-model-64\\thr eadapi-win32\\hello_boost_test.exe" -defaultlib:libcmt "-libpath:C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Professional\\VC\\Tools\\MSVC\\14.13.26128\\lib\\x64" "-libpath:C:\\Program Files (x86)\\Windows Kits\\10\\Lib\\10.0.16299.0\\ucrt\\x64" "-libpath:C:\\Program Files (x86)\\Windows Kits\\10\\Lib\\10.0.16299.0\\um\\x64" -nologo --start-group "..\\..\\..\\bin.v2\\libs\\hello_boost_test\\test\\hello_boost_test.test\\clang-gnu-linux-6.0.0\\release\\address-model-64\\threadap i-win32\\hello_boost_test.obj" "..\\..\\..\\bin.v2\\libs\\test\\build\\clang-gnu-linux-6.0.0\\release\\address-model-64\\link-static\\threadapi-win32\\libboost_uni t_test_framework-clang60-x64-1_66.lib" "..\\..\\..\\bin.v2\\libs\\timer\\build\\clang-gnu-linux-6.0.0\\release\\address-model-64\\link-static\\threadapi-win32\\libboost_ti mer-clang60-x64-1_66.lib" "..\\..\\..\\bin.v2\\libs\\chrono\\build\\clang-gnu-linux-6.0.0\\release\\address-model-64\\link-static\\threadapi-win32\\libboost_c hrono-clang60-x64-1_66.lib" "..\\..\\..\\bin.v2\\libs\\system\\build\\clang-gnu-linux-6.0.0\\release\\address-model-64\\link-static\\threadapi-win32\\libboost_s ystem-clang60-x64-1_66.lib" -Bstatic -Bdynamic --end-group msvcrt.lib C:\LLVM\clang-600\LLVM\bin\lld-link: warning: ignoring unknown argument: --start-group C:\LLVM\clang-600\LLVM\bin\lld-link: warning: ignoring unknown argument: -Bstatic C:\LLVM\clang-600\LLVM\bin\lld-link: warning: ignoring unknown argument: -Bdynamic C:\LLVM\clang-600\LLVM\bin\lld-link: warning: ignoring unknown argument: --end-group C:\LLVM\clang-600\LLVM\bin\lld-link: error: entry point must be defined clang++.exe: error: linker command failed with exit code 1 (use -v to see invocation) Which leaves me baffled. Verbose logs are attached, and I have several others if any kind soul would be willing to pass a more expert eye over them. Ideas on what I am doing wrong most welcome? Thanks. Paul PS I am away for a while, but eagerly await solutions on my return ;-) --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

1 0

Permission to merge bugfix into 1.67 master (geometry)
by Barend Gehrels 29 Mar '18

29 Mar '18

Hi, Can I merge a small bugfix for Boost.Geometry into master? It is about https://github.com/boostorg/geometry/commit/68296965f55d911d74574ae7bbc0652… If allowed, I will cherry-pick this commit into master. Thanks, Barend

3 2