Re: [boost] Making Boost invisible

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

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