Re: [boost] Making Boost invisible

Subject: Re: [boost] Making Boost invisible
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2018-09-25 18:20:27

On 25.09.18 20:08, Zach Laine via Boost wrote:
> 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?

My opinion is that this is not a job for a C++ developer and/or library 
maintainer. Also, we are not shipping compilers with STL or what not, 
and we never claimed to ensure ABI compatibility across versions. All 
those tasks are related, and this is "packaging" to me. This is hard 
work, and I believe we have already enough to do :)

Of course, this is my opinion :)

Raffi