public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "mmarcus at emarcus dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/23628] Typeinfo comparison code easily breaks shared libs Date: Thu, 01 Sep 2005 08:35:00 -0000 [thread overview] Message-ID: <20050901083514.22112.qmail@sourceware.org> (raw) In-Reply-To: <20050829194742.23628.mmarcus@emarcus.org> ------- 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
next prev parent reply other threads:[~2005-09-01 8:35 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2005-08-29 19:55 [Bug c++/23628] New: " mmarcus at emarcus dot org 2005-08-29 19:58 ` [Bug c++/23628] " pinskia at gcc dot gnu dot org 2005-08-29 19:59 ` pinskia at gcc dot gnu dot org 2005-08-29 20:23 ` mmarcus at emarcus dot org 2005-08-29 20:27 ` mmarcus at emarcus dot org 2005-08-29 20:30 ` pinskia at gcc dot gnu dot org 2005-08-29 20:31 ` pinskia at gcc dot gnu dot org 2005-08-29 20:34 ` pinskia at gcc dot gnu dot org 2005-08-29 20:40 ` pinskia at gcc dot gnu dot org 2005-08-29 20:49 ` mmarcus at emarcus dot org 2005-08-29 20:56 ` pinskia at gcc dot gnu dot org 2005-08-29 20:57 ` pinskia at gcc dot gnu dot org 2005-08-29 21:01 ` mmarcus at emarcus dot org 2005-08-29 21:05 ` mmarcus at emarcus dot org 2005-08-29 21:11 ` pinskia at gcc dot gnu dot org 2005-08-29 21:32 ` mmarcus at emarcus dot org 2005-08-29 21:32 ` Andrew Pinski 2005-08-29 21:57 ` pinskia at physics dot uc dot edu 2005-08-29 22:14 ` mmarcus at emarcus dot org 2005-08-30 13:17 ` ghost at cs dot msu dot su 2005-08-30 13:44 ` gdr at integrable-solutions dot net 2005-08-31 7:19 ` ghost at cs dot msu dot su 2005-08-31 14:21 ` pinskia at gcc dot gnu dot org 2005-08-31 14:39 ` ghost at cs dot msu dot su 2005-08-31 14:56 ` gdr at integrable-solutions dot net 2005-09-01 8:35 ` mmarcus at emarcus dot org [this message] 2005-09-01 10:42 ` s_gccbugzilla at nedprod dot com [not found] <bug-23628-10681@http.gcc.gnu.org/bugzilla/> 2006-01-21 21:02 ` rjohnson at dogstar-interactive dot com 2006-01-21 21:45 ` gdr at cs dot tamu dot edu 2006-09-18 21:02 ` geoffk at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20050901083514.22112.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).