|
Boost : |
Subject: Re: [boost] bug-sprint #2114, 2 comments
From: Juergen Hunold (juergen.hunold_at_[hidden])
Date: 2009-06-11 06:12:25
Hi Alexander
On Thursday 11 June 2009 08:58:24 Alexander Arhipenko wrote:
> Hi Juergen,
> So, bar only exports bar::function symbol.
> This is the same for gcc and msvc
> (I've rechecked msvc's case with dumpbin utility).
Point taken. But msvc will add an _import_ reference to "foo::Error" and thus
add a dependency to "foo".
> In case, when foo::Error is re-exported
> (i.e., foo:Error always have 'default' visibility):
> bar: [bar::function, foo::Error].
> This only relates to gcc.
Of course.
> >So why do you want to hide the
> > symbols with gcc ?
>
> The reason could be binary compatibility.
This is a weak point and no concern in my opinion.
I think you can't "hide" a symbol from a 3rd library this way. It definitely
won't work cross platform as at least msvc adds an explicit import reference.
And guaranteeing binary compatibility implies a lot more than simply using
symbol visibility.
I've searched the current KDE trunk and found:
#ifdef __KDE_HAVE_GCC_VISIBILITY
#define KDE_NO_EXPORT __attribute__ ((visibility("hidden")))
#define KDE_EXPORT __attribute__ ((visibility("default")))
#define KDE_IMPORT __attribute__ ((visibility("default")))
so at least KDE uses default visibility for all imported symbols, too.
Lacking more time to do further research, I'd like to add more visibility. We
can try and remove "visibility default" from the import macros once we have
the Boost.Build support up and running and get this thing tested across all
platform.
So I think we should take my original patch.
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 !
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk