------- 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
