On 18/10/2018 16:17, Robert Ramey via Boost wrote:
On 10/18/18 4:12 AM, John Maddock via Boost wrote:
I was about to agree with you, but there is one very important use case - that of the application pluggin. In that situation one would expect that as long as everything is built with -fvisibility-hidden so that each shared library is entirely self contained, then everything should really be fine.
Hmm - I'm not sure about this. Consider the C++ runtime library on windows with msvc. The app specifies dynamic linking of some boost library. I believe that will of necessity use the dynamically linked version of the C++ runtime library. Now we call a plugin which includes another boost library - statically linked this time. The plugin will use the statically linked version of the C++ runtime library.
No not true, just because a Boost library is static, it can still be built against the dll runtime and then everything is just fine. In fact static linking to Boost (even when using the dll runtime) is actually the default behaviour on windows. Best, John.
Now as the program executes, it might be calling different versions of the C++standard library and who knows what else. Sooooo - I would be pretty reluctant to start down this path. Perhaps this is why microsoft, in it's wisdom, has separate "visibility" attributes for import / export.
In any case, this is one aspect that should really be solved at the committee level - but they're occupied with more pressing issues such as the spaceship operator.
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus