http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51930
--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-27 14:56:13 UTC --- (In reply to comment #14) > The new behaviour makes it pretty much impossible for me to retain the > visibility gcc has been giving me with the old behaviour. The old behaviour was buggy, > The push/pop visibility can be done, if one is very careful. Doing this on a > fine grained level is out of the question. You know how C++ includes and their > include guards work. You have to put the push/pop macros around the first > inclusion of such a header, which is almost never possible. If you decide to > go > for a wider push/pop scope (for example all the headers in the TU that does > the > explicit instantiation(s)) then you might end up giving a lot of stuff default > visibility that you don't want to. You could write forwarding headers for the third-party headers and put them earlier in your include path with -I e.g. for foo.h #pragma GCC visibility push(default) #include_next <foo.h> #pragma GCC visibility push > Even if this method would succeed, it would still mean a lot of extra macro > invocations just for gcc-4.7. If you don't want to use that header for older versions of GCC just don't put the directory with the forwarding headers in the include path.
