
On Monday, July 7, 2025 6:51 PM, Christian Mazakas wrote:
Isn't this overcome by just statically linking in the Boost code you need specifically and then making sure none of the symbols are publicly visible?
If the 3rd library uses boost datatypes in its public interface, then there's no way around having to ensure both are compiled against versions of boost that are mutually compatible in the layout and semantics of these data types. To do otherwise is an ODR violation, no matter what kind of linkage they use. Right here, this provides an argument to care about managing ABI breakage. An interesting case study on how to handle such ABI changes is libstdc++'s concurrent support for STL datatypes both before and after the changes introduced by C++11, which involved relegating the legacy versions to their own C++ namespace (see: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html ). If we're merely concerned about incidental boost symbol collisions, then static linkage might indeed be a workaround. However, it has the downside that whenever a bug or security vulnerability -fixed build of the boost version used by your code is released, you must also release a new build. Whereas, a benefit of shared libraries is that the distro could release a fixed build of the boost version you used and the end user benefits without you having to release a new build of your app or the user having to install it. Now, you might wonder how we might simultaneously worry about boost version inconsistencies while still relying on the distro to provide security updates. One distro I use is currently tracking two boost releases, while another is tracking three. So, even sticking with a distro-provided boost, there are still opportunities for inconsistencies to arise relative to what other distro-provided libraries use. This isn't my area of expertise, but a workaround for incidental shared library symbol collisions appears to exist in the form of ELF symbol versioning. I think this could enable multiple versions of boost to be linked into the same executable, without the symbols from one overriding any symbols from the other. If my understanding is correct, this could provide the benefits you sought from static linking, without foregoing the maintenance advantages of dynamic linking. Not that it would alleviate most of the issues stemming from ABI instability, but I think it would address some cases. Matt