Re: [boost] Making Boost invisible

Subject: Re: [boost] Making Boost invisible
From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2018-09-25 18:08:53

On Tue, Sep 25, 2018 at 12:55 PM Raffi Enficiaud via Boost <
boost_at_[hidden]> wrote:

> On 25.09.18 19:38, Zach Laine via Boost wrote:
> > On Tue, Sep 25, 2018 at 10:29 AM Andrey Semashev via Boost <
> > boost_at_[hidden]> wrote:
> >
> >> On 9/25/18 8:08 PM, John Maddock via Boost wrote:
> >>> Folks I have a bug report against Boost.Config that I don't know what
> >>> (if anything) I should do about:
> >>> https://github.com/boostorg/config/issues/243
> >>>
> >>> The issue is this: lets say I build boost as static libraries with
> >>> -fvisibilty=hidden because I want my application or shared library to
> >>> *hide all boost symbols*.  But there are some parts of boost which
> >>> unconditionally make things visible - throw_exception is one particular
> >>> culprit, but there are others, probably anything which uses
> >>> BOOST_SYMBOL_VISIBLE in fact.
> >>>
> >>> Question: should we support this?  If so how?  The only thing I can
> >>> think of is a user-defined macro which when set, disables symbol
> >>> visibility.
> >>
> >> I don't think we need to support this sice the user can already hide any
> >> symbols with linker scripts.
> >>
> >
> > I've seen this done, and it was extraordinarily painful.  To me the need
> > for this is a vote in favor of supporting this feature request, no
> > against.  Having said that, the only reason I know of that any of this
> > should actually be required is in an environment where only static
> linking
> > is allowed (e.g. a game console).
> >
> > Is there a reason the requester could not just link to Boost dynamically?
>
> If you have a plugin that links to boost, and this plugin should be
> loaded by another program that links to another version of boost, you
> may have symbol clashes (mostly on Linux). Dynamic linking does not
> help: a symbol may be overridden by a remote library.
>

Thanks, Rafi.  I find that to be compelling use case.  Is the proposed fix
going to increase library authors' maintenance burdens?

Zach