Hi,
Visibility attribute has notable differences compared to dllexport. For example, all type_info's must be made externally visible in order to have dynamic_cast, exceptions and type_info comparison working (one of the most striking affected libraries is Boost.ProgramOptions, since it is built on top of Boost.Any, which uses type_info).
Also, it affects ODR adherence across modules. E.g. with default visibility "hidden" an address of the same function or global variable may appear to be different in different modules. This is already the case on Windows, though, so I guess this change should not break anything, but still it should be taken into account.
So it doesn't look like a trivial change in settings and macros to me. What's worst, making such a change can trigger problems that are hardly detected by unit tests. Perhaps, we should just mandate the visibility=hidden mode not supported for now. Maybe --fvisibility-ms-compat or --fvisibility-inlines-hidden would be a better choice to support?
I've run into problems with the latter where RTTI would break if all intermediate base classes with virtual destructors did not explicitly define one, e.g.: class EXPORT Base { public: ... virtual ~Base(); ... }; class EXPORT Intermediate : public Base { ... // No explicitly defined virtual destructor. }; class EXPORT Derived : public Intermediate { public: ... virtual ~Derived(); ... }; A dynamic_cast<> from Base to Derived would fail unless the ~Intermediate() destructor was explicitly defined, presumably out-of-line. The last time I experimented with gcc visibility support was a couple of years ago. Perhaps this subtle issue has been addressed or at least improved since then. HTH, -Ossama