From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22172 invoked by alias); 1 Sep 2005 08:35:19 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 22113 invoked by uid 48); 1 Sep 2005 08:35:14 -0000 Date: Thu, 01 Sep 2005 08:35:00 -0000 Message-ID: <20050901083514.22112.qmail@sourceware.org> From: "mmarcus at emarcus dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050829194742.23628.mmarcus@emarcus.org> References: <20050829194742.23628.mmarcus@emarcus.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/23628] Typeinfo comparison code easily breaks shared libs X-Bugzilla-Reason: CC X-SW-Source: 2005-09/txt/msg00046.txt.bz2 List-Id: ------- Additional Comments From mmarcus at emarcus dot org 2005-09-01 08:35 ------- I will add a real-world use case. Lets say that I am the author of a shared library and that today I wish to provide my client, AnApp, with MyLib version 1. I will also need to provide my clients with updated versions in the future, *without breaking binary compatibility*. That is, when version 2 of my library comes out, it must not break AnApp version 1. As a good citizen, I keep my public ABI as narrow as possible, exporting a small number of extern "C" functions. Internally, I make use of various C++ shared libraries including boost version 1.33. It so happens that AnApp version 1 also links to the shared library boost 1.33. For RTTI to work properly, certain names must be shared between boost 1.33 and MyLib version 1, so I add those names to my list of exports. Lets say that one of those names is BoostFoo. AnApp version 1 also exports those names for RTTI compatibility with boost 1.33. A year passes and now I want to release MyLib version 2. I decide that it would be convenient to use the newly released boost 1.35 in my implementation. But what if, say, boost 1.35 has changed the layout of struct BoostFoo? If so, I cannot use boost 1.35 in my implementation since I am exporting BoostFoo--my exported BoostFoo 1.35 will conflict with the BoostFoo 1.33 that AnApp version 1 uses. The requirement that I export the name BoostFoo to my clients in order to for type identity to be shared with my supplier has effectively "revision-locked" me to boost 1.33. Though slightly complex to state, this was not a contrived use-case. For example, people want updates of their Photoshop plugins to work. The suggestion above of comparing typeinfo's by name instead of by address is really just a bandaid. What we really need is some form of directed visibility control where a library exports one set of symbols to the libraries on which it depends, and a different set of symbols to its clients. -- What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23628