I've got a few questions about the "visibility" changes for boost. My understanding is that "visibility" for gcc and clang are "sort of the same thing" as dll import and export are for windows. Now we've made "visibility" the "default". But this seems kind of weird. This has been made a b2 feature. In order to run tests, this feature is applied to the b2 command line. What's weird is that it's applied to the tests/executables and propogated down to libraries which are built. I actually don't know what "visibility" means in the context of building and executable. If I want to use visibility=global then on the library build, it needs to be applied to everything. It's very weird and doesn't seem in line with the windows solution. Heretofore, I've applied visibility to the library build "by hand" by adding the appropriate command line switches to the right places. I'm aware that this is not the b2 way. But the b2 way doesn't seem to make sense to me. On the bright side, changing default visibility didn't seem to have any effect on the serialization library other than on one test. Unfortunately, turning this confused a pending issue and made it even more contentious than it already is/was. FWIW - this is not so much the fault of b2 or anyone in particular. The use of DLLS/shared libraries is the triumph of development over design by vendors, each of whom do their own thing and have never been able to get it together. By now this has created enough technical debt that it will take years to straighten out if people actually start to address it, which no one seems interest in doing. Anyway, the b2 approach is pretty confusing and probably wrong. I'm also guessing that, as one would predict, a change like this is going to provoke subtle failures in lots of small corners which will take quite a while to discover. I'm not sure how to address this. Robert Ramey