Re: [boost] [all] Request for out of the box visibility support

Subject: Re: [boost] [all] Request for out of the box visibility support
From: Edward Diener (eldiener_at_[hidden])
Date: 2018-08-18 13:58:42

On 8/17/2018 11:14 AM, Robert Ramey via Boost wrote:
> On 8/16/18 11:21 PM, Antony Polukhin via Boost wrote:
> 
> This is a worthy idea.  Having a shared library/dll export only those 
> symbols which are required is a big improvement for the user.
> 
> But, there's much more to it than meets the eye.   I implemented this 
> for the serialization library as it was a huge PITA.
> 
> a) The syntax for marking up exported functions is different for 
> microsoft and other compilers.
> 
> b) when a library is built on a lot of nested/inherited classes it 
> becomes non-obvious what to export.
> 
> c) when a library depends upon another library, it can become even more 
> problematic.
> 
> d) when doing stuff like running gcc compiler creating shared library 
> under windows things can get confused.
> 
> e) Our testing matrix doesn't display or maintain different results base 
> on whether a test is being run with shared or static linking.  So the 
> value of the test results is much diminished.  There are so many 
> combinations that one must really depend upon the test results but these 
> don't have the required information.
> 
> f) There was a paper for the standardization committee which included a 
> proposal to help addressing this stuff - but it failed to gain enough 
> interest to get the problem addressed.  In fact, the whole issue of 
> dynamically loaded shared libraries raises a bunch of interesting 
> problems - are global static variables unique?, etc. .  The concept can 
> be very, very powerful in creating large extendable applications, but 
> the C++ language is silent on the whole issue.  It's a serious problem 
> but too unpleasant to actually address.

I do not see any difference, vis-a-vis the visibility problem discussed, 
between dynamically loaded shared libraries or statically loaded shared 
libraries. I agree with you that the problem of visibility is often more 
complicated than what is supposed, given different compilers having 
their own rules regarding visibility on different platforms.