$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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.