Re: [boost] [config] GCC symbol visibility across shared libraries

Subject: Re: [boost] [config] GCC symbol visibility across shared libraries
From: Jürgen Hunold (juergen.hunold_at_[hidden])
Date: 2010-05-20 15:10:38

Hi !

On Thursday, 20. May 2010 17:30:40 you wrote:
> On Thu, May 20, 2010 at 9:54 AM, Alexander Arhipenko <arhipjan_at_[hidden]> 
wrote:
> > On Thu, May 6, 2010 at 7:42 PM, Jürgen Hunold <juergen.hunold_at_[hidden]> 
wrote:
> >> Hi Beman,
> > 
> > Some comments on patch.
> > 
> > 1)
> > The first version of BOOST_SYMBOL_EXPORT/IMPORT macro
> > had slightly different definition for gcc (something like this):
> > #define   BOOST_SYMBOL_EXPORT  __attribute__((visibility("default"))
> > #define   BOOST_SYMBOL_IMPORT
> > 
> > Assume that I've built boost filesystem library with hidden visibility.
> > After that I've used boost filesystem functionality in my custom
> > shared library foo
> > (also build with hidden visibility).
> > Assume also that boost filesystem was used as an implementation detail.
> > You will never find any references to filesystem in foo's public
> > interface.

Ah yes, now I remember the discussion on trac and the old ML thread. 

> > In case when __attribute__((visibility("default")) is always defined,
> > foo's ABI contains boost filesystem's exported symbols also.
> > In case if BOOST_SYMBOL_EXPORT/IMPORT macros defined as above,
> > foo's ABI contains only it's own exported symbols.
> > 
> > In my opinion, shared library ABI should not contain any
> > implementation details.
> > So, I would rather vote for using export/import macros defined as above.
> > Please, correct me if I'm wrong or misunderstood something.

That is a tricky one. I'm not a gcc guru myself, I just use the setup which 
works with our own codebase. 
But I think that ld somehow has to know which symbols to import from  boost 
filesystem so at least weak symbols have to be present in foo.so. This should 
be visible in nm output. 
I doubt that visibility support goes that far. And our own experience with it 
have been quite disappointing for the proposed decrease in librarie size and 
link time...
We should investigate that further. I hope I can do some tests over the 
weekend...

> My patch was based on Jürgen's original " #define
> BOOST_SYMBOL_IMPORT". We need to get input from him as to why that
> changed in his second patch.

Which one ? The second on trac ? Long ago ...
 
> > 2)
> > What do you think about having BOOST_SYMBOL_EXPORT/IMPORT always defined?
> > This will decrease #ifdef branches in libraries configuration files
> > (config.hpp).
> 
> I just tried that on <boost/system/config.hpp>, and it is quite a bit
> shorter (12 loc vs 19 loc), reads better, and is probably easier to
> teach. So unless someone objects, I'll follow your suggestion.

Yes, please go that way. 
I was lacking the courage to do such invasive changes at this stage. The goal 
should be to reduce the per-library code as much as possible.

Yours,

Jürgen
-- 
* Dipl.-Math. Jürgen Hunold       ! Ingenieurgesellschaft für 
* voice: ++49 511 262926 57       ! Verkehrs- und Eisenbahnwesen mbH  
* fax  : ++49 511 262926 99       ! Lister Straße 15
* juergen.hunold_at_[hidden]        ! www.ivembh.de
* 
* Geschäftsführer:                ! Sitz des Unternehmens: Hannover
* Prof. Dr.-Ing. Thomas Siefer    ! Amtsgericht Hannover, HRB 56965
* PD Dr.-Ing. Alfons Radtke       !