Making Boost invisible

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Making Boost invisible

Boost - Dev mailing list
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.

Thoughts?

Thanks, John.



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Making Boost invisible

Boost - Dev mailing list
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.

http://man7.org/conf/lca2006/shared_libraries/slide18c.html

Also, a thing to note is that I think there are a few places where Boost
relies on some symbols being defined by user, which means they should be
either defined in the same executable or exported from another. For
instance, tss_cleanup_implemented from Boost.Thread works like this.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Making Boost invisible

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 9/25/2018 1: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.
>
> Thoughts?

Isn't it up to each built library to determine what symbols should be
visible or not in order to use that library ? In general public and
protected class functionality should be visible, and functions which are
part of the library's public interface are visible, with everything else
remaining hidden. If an end-user wants to override this for some
personal reason there should be a mechanism for doing so, but I would
normally see little reason why an end-user should want to do that. What
harm can it be to allow normally visible symbols to remain visible for
the end-user ?

>
> Thanks, John.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Making Boost invisible

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Tue, Sep 25, 2018 at 10:29 AM Andrey Semashev via Boost <
[hidden email]> 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?

Zach

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Making Boost invisible

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 25.09.18 19:08, 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.
>
> Thoughts?
>
> Thanks, John.

I was trying to do that for a Matlab extension that had dependencies on
Boost. The symbols of my extension were clashing with the Boost shipped
with Matlab.

My findings were that the hidden (+/- inline) visibility helps a bit,
but does not make boost totally invisible. You will need additional
compiler options on Linux and OSX. One of those compiler options is the
map file that indicates which symbols should be exported, in a verbose
fashion.

Example of map file:
https://github.com/MPI-IS/Grassmann-Averages-PCA/blob/master/extensions/MatlabLinuxVisibility.map

How to inject this in the build:
https://github.com/MPI-IS/Grassmann-Averages-PCA/blob/master/CMakeLists.txt#L495-L496

Concerning the exceptions, if their handling is internal to the library,
I believe they can stay hidden. If they need to be caught, they
obviously need to be exported.

My opinion is that that those things are rather "integration" or
"system" level that depend on different scenarios and environments. I do
not think that this work should be shifted from library or package
integrators to boost C++ developers.

Best regards,
Raffi


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Making Boost invisible

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 25.09.18 19:38, Zach Laine via Boost wrote:

> On Tue, Sep 25, 2018 at 10:29 AM Andrey Semashev via Boost <
> [hidden email]> 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.

Raffi




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Making Boost invisible

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
John Maddock 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.

That's the only thing we can do. #ifdef something, #define
BOOST_SYMBOL_VISIBLE to nothing, let them deal with whatever happens.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Making Boost invisible

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Tue, Sep 25, 2018 at 12:55 PM Raffi Enficiaud via Boost <
[hidden email]> 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 <
> > [hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Making Boost invisible

Boost - Dev mailing list
On 25.09.18 20:08, Zach Laine via Boost wrote:

> On Tue, Sep 25, 2018 at 12:55 PM Raffi Enficiaud via Boost <
> [hidden email]> 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 <
>>> [hidden email]> 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




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Making Boost invisible

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
вт, 25 сент. 2018 г. в 21:08, Peter Dimov via Boost <[hidden email]>:
> John Maddock wrote:
<...>
> > 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.
>
> That's the only thing we can do. #ifdef something, #define
> BOOST_SYMBOL_VISIBLE to nothing, let them deal with whatever happens.

+1. Do that and let people seek and hide symbols.

--
Best regards,
Antony Polukhin

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost