On 1 Sep 2026 01:01, Ion Gaztañaga via Boost wrote:
In Boost 1.93, a private new utility (detail/intermodule_globals.hpp) provides a class (dtl::intermodule_globals<T, Options>) that returns a reference to a single object of type T for each T/Options pair.
The object is shared by every module in the process. It is constructed on zero-initialized storage by whichever module reaches it first with some configurable options (like a phoenix singleton for those globals that need to be available to the very end of the program, like a heap allocator). The dlmalloc globals and the PMR globals are the only two users inside the library.
On ELF and Mach-O the global object is implemented as a static data member of a class template, with default visibility (so that the loader unifies all the instances from each .so and .elf).
Note that symbols with default visibility may still be hidden with linker scripts. The scripts may be part of the user's build setup, so he would have to update the script to export the symbols. Which means, the symbols must be documented and not just an implementation detail. Also, this new approach to process-wide globals requires that all TUs (including in different shared objects) are compiled against the same Boost with the same settings to maintain binary compatibility. With a compiled shared library, this was somewhat easier to do. I'm not sure if you're checking for ABI mismatch in the new implementation, but if not, I think you should, and there should be a reasonable behavior in case of ABI mismatch. Otherwise, ABI mismatch issues can be very difficult to debug, especially if some parts of the application are not written by the user (e.g. when he uses a third party library that he doesn't know how it was compiled and with what Boost version).