Thomas Weber <[email protected]> writes: > On Fri, Jan 06, 2012 at 05:14:32PM -0800, Russ Allbery wrote:
>> If it's a private symbol not intended to be used by clients and that >> wouldn't naturally be used by clients, you can mark it optional in the >> symbols file (symbol tag optional), and then the symbols generation >> won't care if it appears and disappears. > This doesn't answer my question, does it? I mean, your statement is true > for whatever symbol that appears in the symbol file. My question is > about inlined class methods specifically and the fact that the compiler > might change its opinion about them with even minor version bumps. The question I think we have to ask here is whether the disappearance of the declared-inline constructor from the exported symbols of the library would ever break a package that was linked against it. My guess is no; my guess is that while the compiler may choose whether or not to provide a non-inline version of the symbol in the library, software built against the library will always inline the constructor and not generate a reference to the symbol. That was the assumption under which I suggested using optional. But I don't know enough about C++ to be sure that I'm right about this. If it is the case that binaries linked against the library may declare a reference to that symbol, then the symbol is indeed part of the ABI, and the build failing because the symbol disappeared indicates a real bug in the package. If the symbol randomly appears and disappears but is needed by clients, that would be a real bug in g++ so far as I can tell, since it makes it impossible to safely maintain the library ABI. But this seems unlikely to me, since this would be a rather huge thing for the g++ developers to miss. If the behavior is just different on different architectures but consistent on an architecture, the right solution may be to use symbol tags to provide an architecture list rather than marking it optional, so that we ensure the symbol continues to be present on those architectures. > One of the things that I find frustrating is the total lack of reliable > and complete documentation about symbols; yet library maintainers are > expected to keep the symbols file sane. > Example from dpkg-gensymbols (5): > "For example, most of C++ template instantiations fall into this > category" (it's talking about optional symbols here). > So, which template instantiations are *not* safe to be tagged as > optional? This is a different question, but I have quite some template > instantiations in the symbol file as well. symbols was originally developed for C libraries, and C++ really wasn't supported originally. I think you're still seeing the remnants of that. Part of the problem is that the behavior of C++ is obscure, since C++ is a *far* more complex language, and I don't think that the people who have worked on this support are necessarily C++ experts. What would be very helpful would be documentation written by someone who *is* a C++ expert and who understands how library and symbol exports work with C++. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
