* Christoph Egger <firstname.lastname@example.org>, 2010-03-11, 19:31:
Currently irrlicht released a new minor version which I want to upload to debian. Concerning the ABI the only relecvant change is the removal of 4 symbols which are template instantiations. I can, of course, force instantiation of these templates but that feels quite like a hack. Does someone with deeper insight into that topic know if just having that ABI change causes some potential harm or whether I can just go ahead ignoring it?
[Disclaimer: I'm neither a shared libraries expert, nor a C++ expert. The following text is based only on my shallow knowledge and a couple of experiments.]
If we are very rigid, then unfortunately it is possible that some programs/libraries are already using these symbols and having them gone is an ABI breakage. But then we are doomed anyway: it is also possible that some symbols will disappear after a simple recompilation, just because compiler decided to inline more stuff than previously.
So, going back to reality: If we can assume some level of sanity, i.e.:- these templates are fully defined within the library headers (in all versions using the same SONAME);
- all software is actually using the library headers;then it *looks* like that gcc will never generate binaries with the symbols in question undefined. Thus, it would be safe ignore disappearance of them.
Side note #1: According to dpkg-gensymbols(1), “A symbol marked as optional can disappear from the library at any time and that will never cause dpkg-gensymbols to fail. […] most of C++ template instantiations fall into this category.” Now let's merely define “most”…
Side note #2: I have the impression that maintaining shared libraries is a poorly understood topic for most upstreams *and* for most DD. However I also believe that we have some people within the project who are very knowledgeable about that. It is therefore sad that we lack good and properly maintained documentation on that matter.
-- Jakub Wilk
Description: Digital signature