On Wed, Apr 23, 2014 at 10:41:06AM +1200, Robert O'Callahan wrote: > On Wed, Apr 23, 2014 at 1:25 AM, Benjamin Smedberg > <[email protected]>wrote: > > > On 4/22/2014 7:31 AM, Robert O'Callahan wrote: > > > >> It's all over the tree, inconsistently applied. Is it relevant anymore? > >> Can > >> we remove it entirely, or there some places where it's still relevant, and > >> if so, where ... XPCOM? Or should we be using it everywhere? > >> > > > > Short answer: I don't think it's relevant any more. > > > > Long answer: Each compiler and platform is a little different, so here's > > my take on where we are: > > > > * Windows/MSVC. NS_HIDDEN never had any effect; symbols are hidden by > > default and need dllexport to be exported > > * Mac/GCC or clang. We compile with -fvisibility=hidden. This means that > > all symbols are hidden by default and you need NS_EXPORT to mark them as > > exported/dynamic. Declarations are treated as dynamic. However because > > Mach-O executables use direct relocations, there is no actual difference > > between the generated code referencing a hidden or dynamic symbol, so we're > > fine. > > * Linux/GCC or clang. We compile with #pragma visibility. This means that > > all symbols and declarations are treated as hidden by default and require > > NS_EXPORT if they are exported/dynamic. > > > > On B2G and Android we're compiling with -fvisibility=hidden. configure > output says: > > checking For gcc visibility bug with class-level attributes (GCC bug > 26905)... yes > checking For x86_64 gcc visibility bug with builtins (GCC bug 20297)... yes > > Is that a problem?
No, that's just how we choose between #pragma visibility and -fvisibility=hidden Mike _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
