- Boost - lists.preview.boost.org

Getting stated with boost and CMake
by pbristow＠hetp.u-net.com 24 Feb '21

24 Feb '21

Having spent a decade watching the Cmake versus bjam/b2 battle, I had thought it wise to wait until the dust has settled. It would appear that the enthusiasm for CMake and Boost is much greater among consumers than producers ☹ But recently I have been working on a project that is possible Boost library and thought that I would dip my toe in the water. After some research, I am still puzzled how I should replace a simple b2/bjam program (say a classic “hello World”) that is run like this \example > b2 -a toolset=msvc,gcc,clang cxxstd=14 release > my_log.log The jamfile contains run hello_world.cpp ; # Simplest hello_world, no other includes apart from iostream. And the b2 run .log contains some outputs of "Hello world" and 3 nice **passed** lines and ...updated 3(?) targets..., one for each compiler (and version too, perhaps with some potentially using build info too), and return exit_success value. (I also would expect to get a simple setup to run a test using the /included version of unit_test_framework. Trying to walk before I fall over running, I have avoided any pre-compiler libraries, at least at first.) After some research (getting as far as generating a Visual Studio project, where I can intervene manually to build and run my hello_world program), I am still unclear how to replicate this b2 test to end with a .exe run and some log file with pass/fail indications. I am of course building on Windows 10 with three recent versions of MSVC, GCC and Clang compilers working, and in my bjam/b2 user-config.jam. Advice from less-than-novice CMakers most welcome. Thank you. Paul

1 0

GSoC 2021 new policies
by Pranam Lashkari 23 Feb '21

23 Feb '21

Hello, To all the potential mentors and students this year GSoC is different from all the previous seasons, so whenever you are planning/proposing/adding a project in GSoC this year, keep the following things in mind: *Smaller project size** - *all students participating in the 2021 program will be working on a 175 hour project (instead of a 350 hr project). *Shortened coding period* - the *coding period will be 10 weeks* with a lot more flexibility for the mentor and student to decide together how they want to spread the work out over the summer. *2 evaluations (instead of 3)* - There will be an evaluation after 5 weeks and the final evaluation will take place after the 10th week. -- Thank you, Pranam Lashkari, https://lpranam.github.io/

1 0

Releasing property_tree updates
by Jared McIntyre 20 Feb '21

20 Feb '21

I noticed there are several updates that have merged into the develop branch for property_tree, but it seems none of them have made it into master for release. Is there any chance that a new version with the fixes may be pushed out in a future release? Thanks, Jared

2 1

boost test: first test organization examples using deprecated init_unit_test_suite?
by Dennis Luehring 15 Feb '21

15 Feb '21

according to this example, i should use init_unit_test_suite https://www.boost.org/doc/libs/1_75_0/libs/test/doc/html/boost_test/tests_o… but it seems that init_unit_test_suite function is deprecated (starting with 1.59) https://www.boost.org/doc/libs/1_75_0/libs/test/doc/html/boost_test/adv_sce… so its unclear to me if i should (still) use this deprecated function or go witht BOOST_AUTO_TEST_SUITE/BOOST_AUTO_TEST_CASE

1 0

[build] "Unknown target type EXE"
by John Maddock 09 Feb '21

09 Feb '21

I've managed to get various architectures tested in qemu-emulation in this PR: https://github.com/boostorg/config/pull/366, with help from https://github.com/uraimo/run-on-arch-action However, for armv7 alone I see: /home/runner/work/config/boost-root/tools/build/src/build/type.jam:158: in type.validate from module type error: Unknown target type EXE (builtin):-1: in sequence.transform from module sequence /home/runner/work/config/boost-root/tools/build/src/build/generators.jam:239: in generator.__init__ from module object(installed-exe-generator)@4 /home/runner/work/config/boost-root/tools/build/src/tools/stage.jam:568: in class(a)installed-exe-generator.__init__ from module object(installed-exe-generator)@4 /home/runner/work/config/boost-root/tools/build/src/kernel/class.jam:90: in new from module class /home/runner/work/config/boost-root/tools/build/src/tools/stage.jam:596: in load from module stage /home/runner/work/config/boost-root/tools/build/src/kernel/modules.jam:295: in import from module modules /home/runner/work/config/boost-root/tools/build/src/tools/builtin.jam:27: in load from module builtin /home/runner/work/config/boost-root/tools/build/src/kernel/modules.jam:295: in import from module modules /home/runner/work/config/boost-root/tools/build/src/build-system.jam:12: in load from module build-system /home/runner/work/config/boost-root/tools/build/src/kernel/modules.jam:295: in import from module modules /home/runner/work/config/boost-root/tools/build/src/kernel/bootstrap.jam:139: in boost-build from module /home/runner/work/config/boost-root/boost-build.jam:17: in module scope from module This is while running ./b2 headers. The initialization/setup code is the same for each architecture as they're run in a GHA matrix so I don't think I've goofed in the CI script. Anyone any ideas what might cause this? Many thanks, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1

New Boost.Build regression/failure
by John Maddock 08 Feb '21

08 Feb '21

This: https://ci.appveyor.com/project/jzmaddock/config/builds/37592647/job/l6ogy7… Has just started failing. Any ideas anyone? Thanks, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

4 8

[Flyweight] Hidden symbol visibility
by Deniz Bahadir 08 Feb '21

08 Feb '21

Hi there, I recently made some interesting observation regarding Boost.Flyweight and (hidden) symbol visibility and have now some questions regarding this. Background story: ----------------- In our company's code base we have been using Boost.Flyweight for several years now, compiling it with GCC (and Clang) and it worked just fine. (Thanks for it!) However, lately we are trying to apply hidden symbol visibility to our code base and some of our unit-tests started failing mysteriously. After some intensive investigation I found out that it seems to be due to how we used Boost.Flyweight. We are instantiating it with some custom types, using the default `boost::flyweights::static_holder` class, and are compiling it into a shared library A. However, these Boost.Flyweight types are not only used within that shared library A but also in some other shared library B and in some unit-test executables which link against shared library A. (And these unit-tests started failing.) Observations: ------------- Reading the documentation of Boost.Flyweight and looking at the header `boost/flyweight/static_holder.hpp` I realized that we should have used `boost::flyweights::intermodule_holder` in the first place instead of `boost::flyweights::static_holder`, because we were using Boost.Flyweight from different shared libraries. Still, with non-hidden visibility applied everything always worked correctly even when using `boost::flyweights::static_holder`. Looking at the generated symbols in the different shared libraries I realized that these `static_holder` class types were marked as "unique global symbol" (an GNU extension to the standard set of ELF symbol bindings). So, all shared libraries and executables still used the same single instance of that `static_holder` class (which is the reason why everything worked). With hidden symbol visibility applied by default, these symbols are now marked as local symbols (from the BSS section). So, each shared library as well as the executables have their own version of the `static_holder` class types (which would explain why the equality-comparisions between different Boost.Flyweight variables in our unit-tests now started failing). If I understand it correctly, using `boost::flyweights::intermodule_holder` is the right thing to do, in particular with hidden symbol visibility. Questions: ---------- 1. However, apart from longer program startup times, what other disadvantages might it have to use the `intermodule_holder` instead of the `static_holder` (assuming it still would be marked as "unique global symbol")? 2. And if, as it seems, `static_holder` has some advantages in general, would it be possible to (maybe conditionally) mark the `static_holder` (and/or `static_holder_class`) class with `BOOST_SYMBOL_VISIBLE` or something similar to allow using it even with hidden symbol visibility from different shared libraries? - Only applying default visibility to the template instantiations is ignored by GCC (with warning: "type attributes ignored after type is already defined [-Wattributes]"). - Besides, the C++ standard does not allow applying C++ attributes to template instantiations. (There was a proposal for allowing it, wg21.link/p0537, but I do not know what happened to it.) 3. Would you have any other recommendations or suggestions I did not think about? Thanks for any help or opinion, Deniz -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Reuchlinstr. 10 D 10553 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir(a)benocs.com www.benocs.com Board of Management: Stephan Schroeder, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378

2 2

BinTray is going away....
by Marshall Clow 06 Feb '21

06 Feb '21

My Friday morning email: > Thank you for supporting JFrog through your use of Bintray. We are and continue to be a community-focused company, and in the spirit of transparency we’re giving you advance notice that as of May 2021, we will be sunsetting Bintray. Just a heads up for now. — Marshall

2 1

Wrong class export/visibility setting for shared libs in many Boost libs
by Alexander Grund 02 Feb '21

02 Feb '21

Hi Boost maintainers, TLDR: Check your classes if they use BOOST_*_DECL and change that to BOOST_SYMBOL_VISIBLE In Boost.ProgramOptions I discovered an issue as a user, where I was unable to catch an exception thrown from the shared Boost library in an executable when both are build with hidden visibility. It turns out the exception class was marked with BOOST_PROGRAM_OPTIONS_DECL which evaluates to "visible" when building the DLL but to nothing when using it. This makes the linker (in theory) mark the typeinfo as hidden which means that the class thrown by Boost and the one tried to catch are unrelated. See https://gcc.gnu.org/wiki/Visibility > Symbol visibility is "default" by default but if the linker encounters just one definition with it hidden - just one - that typeinfo symbol becomes permanently hidden (remember the C++ standard's ODR - one definition rule). This is pretty clear that the current approach done by some Boost libraries doesn't/shouldn't work and BOOST_SYMBOL_VISIBLE should be used instead (or BOOST_SYMBOL_IMPORT should expand to BOOST_SYMBOL_VISIBLE. This depends on how MSCV/Win32 platforms handle class visibility as on Win32 BOOST_SYMBOL_VISIBLE expands to nothing. Maybe someone can clarify here.) As another datapoint: https://github.com/boostorg/config/blob/5bcaa933b55dd58797775d87605a6cdef4a… documents BOOST_SYMBOL_VISIBLE as the macro to be used for this. Libraries which are (very likely) affected by this (quick grep) include: Chrono Container Context Contract Coroutine Fiber Filesystem IOStreams JSON Locale MPI ProgramOptions Python Regex Test Thread Timer Seemingly Linux platforms are less strict in actually enforcing this, due to reason unknown to me. See my SO question: https://stackoverflow.com/questions/65951466/why-can-a-thrown-exception-wit… Reason why this went undetected so far are the above (works on some Linux, fails on e.g. OSX) and that user programs may often not be build with hidden visibility AND rely on the exact same typeinfo from the Boost library (most prominent: exceptions, dynamic_cast) Regards, Alex

5 40

Re: [boost] Wrong class export/visibility setting for shared libs in many Boost libs
by Peter Dimov 02 Feb '21

02 Feb '21

E.g. https://godbolt.org/z/vM6Gxd -----Original Message----- From: Peter Dimov Sent: Tuesday, February 02, 2021 17:01 To: boost(a)lists.boost.org Subject: Re: [boost] Wrong class export/visibility setting for shared libs in many Boost libs Niall Douglas wrote: > I seem to be having difficulty communicating this to anyone here, so > here's a godbolt: > > https://godbolt.org/z/jv5Y75 But you've provided a definition for thirdpartylib_nothidden. This is not the case under discussion. The case under discussion is making BOOST_SYMBOL_IMPORT imply _VISIBLE, which translates to a default visibility attribute on the _declaration_ of thirdpartylib_nothidden.

1 0