- Boost - lists.boost.org

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

Google Summer of Code
by Radu Cosma 30 Jan '21

30 Jan '21

Good afternoon, My name is Radu Cosma and I would like to be a contributor to the Boost C++ Libraries in the context of Google Summer of Code 2021 (as a start :) ). I understand that the topics have yet to be posted and that there is a competency test involved. Could you please tell me the relevant information regarding this and the application process? Thank you in advance! Kind regards, Radu Cosma

1 0

What's the reason Boost.Asio tss_ptr doesn't use __declspec(thread) on Windows?
by Groke, Paul 29 Jan '21

29 Jan '21

Hi, I've noticed that Boost.Asio's tss_ptr implementation doesn't use __declspec(thread) on Windows, except when compiling for WinRT. Instead it uses the win_tss_ptr implementation - which will cause a crash when there's no free TLS index. (There are static tss_ptr instances and loading a DLL where a ctor of a static variables throws a C++ exception seems to cause a crash -- no surprise there). AFAIK using implicit TLS via __declspec(thread) should fix this so that loading a DLL either works or fails gracefully. One problem that I know of with implicit TLS is that it fails catastrophically on Windows versions before Vista. Since WinRT wasn't available on pre-Vista versions, this might be a reason to restrict it to WinRT. But I don't know if there are/were other reasons to restrict use of implicit TLS to WinRT. So... is there another reason? If there's no other reason, that would be great, because we don't have to support pre-Vista versions. Meaning we could simply patch Boost.Asio to use implicit TLS for MSVC in general. Regards, Paul Groke

1 0

Have we become too Intel x64 centered?
by John Maddock 28 Jan '21

28 Jan '21

I have no solution for this, but I note that neither do we have CI, nor tests on https://www.boost.org/development/tests/develop/developer/summary.html that aren't Intel x86. The compiler list has shrunk to msvc/clang/gcc as well. I note that at least in theory, other platforms/architectures could be integrated into Drone CI (either the CppAlliance one, or our own), but someone would have to offer to host the clients running the tests. Any thoughts/solutions? Cheers, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

21 54

Introduction
by Aman Verma 28 Jan '21

28 Jan '21

Hello Boost C++ Community, I am Aman from Indian Institute of technology Kanpur and currently, I am pursuing my bachelor's in Electrical engineering. I have 3 years of experience in C++. I am extremely eager and excited about contributing to various projects of Boost C++. I am willing to participate in GSOC'21 with Boost C++. I have gone through the project proposals and I find myself interested in the following projects: 1. ublas 2. Multiprecision 3. Geometry I would great if I could connect with the respective mentors and move onto further steps. Regards Aman

2 1

boost.numpy functions are throwing unresolved extern symbol link errors
by Max Fetz 20 Jan '21

20 Jan '21

Hello Boost-Community I have asked the following question everywhere but nowhere has it been answered. I have now been advised to ask here. I really hope there is someone on this mail list who can help me. Unfortunately I don't have much time left and would be very grateful for an answer. With kind regards Max My Question: I'm using normal Boost.NumPy functions in C++ like ndarray::get_data(), and I get a "reference to unresolved external symbol" error. The .lib's are linked and I have no approach on how to solve the error. I am using Boost 1.74. Here is a Code example: #include<boost/python/numpy.hpp> using namespace boost; void func(python::object _obj) { python::numpy::ndarray my_ndarray = python::extract<boost::python::numpy::ndarray>(_obj.attr("Member_01")); char* data = my_ndarray.get_data(); } BOOST_PYTHON_MODULE(ogwa_acc) { python::def("func", func); } Thats the one of the unresolved symbols: ""__declspec(dllimport) public: char * __cdecl boost::python::numpy::ndarray::get_data(void)const " (_imp?get_data@ndarray@numpy@python@boost@@QEBAPEADXZ)" I am using the normal Visual Studio linker and this is my linker config: /OUT:"D:\OthelloGame_withAI\x64\Debug\ogwa_acc.pyd" /MANIFEST /NXCOMPAT /PDB:"D:\OthelloGame_withAI\x64\Debug\ogwa_acc.pdb" /DYNAMICBASE "boost_numpy38-vc142-mt-gd-x64-1_74.lib" "boost_numpy38-vc142-mt-x64-1_74.lib" "boost_python38-vc142-mt-gd-x64-1_74.lib" "boost_python38-vc142-mt-x64- 1_74.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /IMPLIB:"D:\OthelloGame_withAI\x64\Debug\ogwa_acc.lib" /DEBUG /DLL /MACHINE:X64 /INCREMENTAL /PGD:"D:\OthelloGame_withAI\x64\Debug\ogwa_acc.pgd" /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"x64\Debug\ogwa_acc.pyd.intermediate.manifest" /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:"C:\Program Files\Python38\libs" /LIBPATH:"D:\OthelloGame_withAI\Third-Party\boost_1_74_0\finished_libs" /TLBID:1 D:\OthelloGame_withAI\Third-Party\boost_1_74_0\finished_libs is the location of: boost_numpy38-vc142-mt-gd-x64-1_74.lib; boost_python38-vc142-mt-gd-x64- 1_74.lib; boost_numpy38-vc142-mt-x64-1_74.lib; boost_python38-vc142-mt-x64-1_74.lib

4 4