Re: [boost] questions regarding GCC visibility

Subject: Re: [boost] questions regarding GCC visibility
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-04-01 15:05:38

On 1 Apr 2015 at 8:06, Robert Ramey wrote:

> Everything looked good.  Then I pushed the change to git hub and watched the
> development results - and they are starting to show failures. So that is how
> I got to where I am.

Force a purge in your Jamfile using the SHELL command. Push that. You 
need to purge on the test machines, not your own.

One quick way of verifying this is to add Travis support. It's always 
a clean build no matter what.

> I should note that the same attribute tags, macros, etc are used to
> export/import symbols for the windows system and this has been working well
> for many years.  The only change in that was I that I used the more recent
> BOOST_SYMBOL_EXPORT/IMPORT macros to make things more readable.  Since the
> windows tests seem to work well, I'm feel comfortable in concluding that
> this change hasn't had any ill effects.
> 
> I'm guessing that are some subtle differences in the rules between the two
> platforms.  The gcc documentation on the subject is suspiciously complicated
> compare to the windows explanation.

The original page I wrote for the feature is at 
http://www.nedprod.com/programs/gccvisibility.html. It may have 
useful detail missing in other guides.

There are subtle differences, mainly because declspec is part of the 
type whereas attributes are not. If you follow my guide in your 
conversion, it'll work. I think that's only how Boost implements 
visibility support because I vaguely remember Dave asking me for a 
favour to do the Boost support for him.

> I could restore the previous of the jamfile which comments out the
> visibility=hidden switch.  But I feel that I'm pretty close to getting it
> right and I think that excluding extraneous stuff from the shared library
> objects make for a better product.  So I'll spend a little more time on it
> before I give up.

fvisibility-inlines-hidden is an alternative. It'll always work with 
no source changes needed. I can't remember if fvisibility >= 
fvisibility-inlines-hidden, I would have thought so.

> PS - one post mentioned the possibility of assigning a visibility attribute
> to a whole namespace.  This looks interesting but I never saw it anywhere. 
> It's also unclear whether or not it's portable

It isn't. MSVC has nothing like it.

There is also a #pragma visibility. I remember that being quite fun 
to implement, unlike the fvisibility which was a PITA. GCC source 
code for the C++ compiler is awful. The preprocessor's, on the other 
hand, was a lovely piece of coding.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/