Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 198967 - new C++ visibility doesn't work as expected
new C++ visibility doesn't work as expected
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2006-07-14 23:35 EDT by Bill Nottingham
Modified: 2014-03-16 23:00 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-22 12:49:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 19664 None None None Never

  None (edit)
Description Bill Nottingham 2006-07-14 23:35:08 EDT
Version-Release number of selected component (if applicable):


WARNING: C++ doofus here.

Consider the following foo.cpp:

#include <list>

class __attribute__((visibility("default"))) Foo {
        std::list<std::string> Bar();


$ g++ -Wall -c -o foo.o foo.cpp -fvisibility=hidden
foo.cpp:8: warning: ‘std::list<std::basic_string<char, std::char_traits<char>,
std::allocator<char> >, std::allocator<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > > > Foo::Bar()’ declared with
greater visibility than its type

Shouldn't the standard libstdc++ template types (std::list, etc) be visible?

Adding #pragma GCC visiblity push & pop around the "#include <list>" fixes it,
but that seems wrong.
Comment 1 Bill Nottingham 2006-07-14 23:37:18 EDT
Erm, assume there's a #include <string> in there. :)  It still errors...

Comment 2 Jakub Jelinek 2006-07-15 03:44:35 EDT
I thought libstdc++ (particularly bits/c++config) already uses
__attribute__((visibility ("default"))) on the std namespace (and similar
namespaces), but apparently it doesn't.
Comment 3 Jakub Jelinek 2006-07-15 07:09:12 EDT
This isn't anything new BTW, it has never been there so far and thus code
without default visibility around the standard headers has always been broken.
Comment 4 Bill Nottingham 2006-07-17 09:31:49 EDT
Ok, then rather than munge all the #include statements in the package, I can
turn off the visibility flag for the build for now. Any chance that at least
libstdc++ could be fixed to have proper visiblity in the headers?
Comment 5 Jakub Jelinek 2007-09-22 12:49:16 EDT
GCC 4.3 will have that, but for 4.1 such changes are IMHO way too invasive.

Note You need to log in before you can comment on or make changes to this bug.