From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2494 invoked by alias); 4 Feb 2009 02:51:54 -0000 Received: (qmail 2470 invoked by uid 48); 4 Feb 2009 02:51:43 -0000 Date: Wed, 04 Feb 2009 02:51:00 -0000 Message-ID: <20090204025143.2469.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/36022] stl templates exported as weak symbols though visibility hidden is used In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "bkoz at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-02/txt/msg00306.txt.bz2 ------- Comment #4 from bkoz at gcc dot gnu dot org 2009-02-04 02:51 ------- This isn't a bug, but rather part of a deliberate linkage strategy. For C++, types that are to be used across shared libraries have to be visible. See: http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options And in particular: Note that `-fvisibility' does affect C++ vague linkage entities. This means that, for instance, an exception class that will be thrown between DSOs must be explicitly marked with default visibility so that the `type_info' nodes will be unified between the DSOs. Thus, the rationale for libstdc++ having namespace std have visibility "default." If you were to hack in support for allowing namespace std to have hidden visibility, and run the testsuite with -fvisibility=hidden (see attached patch) you would notice the breakdown in testresults, with mass failures. Thus, it is provided for information purposes only. In the libstdc++ source files, anonymous namespaces are used for specific entities that have both local/hidden linkage. This use of anonymous namespaces is considered superior to attribute hidden as it uses ISO C++ and is thus more portable than vendor extensions (pragmas or attributes). However, in libstdc++ header files, attribute hidden has been difficult to use. One might think that perhaps all the implementation details could be moved to say std::__detail, and then marked with attribute hidden. Then, many of these helper functions would be marked as hidden in your example below. There are some pitfalls with this approach: 1) all these implementation base types that are used by default derived classes would have to be default 2) same with implementation details that use static locals 3) same with virtual functions, etc etc. 4) thus you end up with a pretty limited set of hidden things In addition, this may exacerbate the dlopen + RTLD_LOCAL + weak symbol issue for C++. -- bkoz at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- GCC host triplet| |x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36022