Date: Tue, 12 Nov 2002 18:44:53 -0600 (CST) From: Loren James Rittle <rittle@latour.rsch.comm.mot.com> To: tlambert2@mindspring.com Cc: current@freebsd.org Subject: Re: binutils symbol hiding and versioning (was Re: [PATCH] note the __sF change in src/UPDATING) Message-ID: <200211130044.gAD0irOo005833@latour.rsch.comm.mot.com> In-Reply-To: <3DD0B80B.2279721@mindspring.com> (message from Terry Lambert on Tue, 12 Nov 2002 00:12:59 -0800) References: <3DCADE51.2090607@acm.org> <200211120553.gAC5rQFi093274@latour.rsch.comm.mot.com> <3DD0B80B.2279721@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <3DD0B80B.2279721@mindspring.com>, Terry Lambert<tlambert2@mindspring.com> writes: > Loren James Rittle wrote: >> FYI, the libstdc++-v3 maintainers on the FSF side are only >> guaranteeing forward ABI compatibility of any sort if libstdc++.so is >> built with symbol versioning and symbol hiding. > FWIW: symbol versioning is incredibly broken. It attempts to > do in UNIX what interface versioning does in Windows, through > the use of class factories accessed via IUnknown. You might be absolutely correct in general. However, please read http://gcc.gnu.org/onlinedocs/libstdc++/abi.txt . It is clear that symbol versioning is not being used at all like you supposed it might have been (mis-)used. FWIW: There is no concept of IUnknown or implementation factories (and, yes, I do understand those concepts) in how libstdc++.so (v3) is using symbol versioning. I invite you to take a close look at how that library is actually using symbol hiding and versioning before you attempt to cast your judgment. If you have informed comments, then please direction them to libstdc++@gcc.gnu.org not me personally (as a libstdc++-v3 maintainer, I will read them over there like all others). Short summation: We only mark the first version of the library that a new symbol is added. E.g. there will never be X@3.2 and also X@3.2.1. The first release after an ELF library version number bump resets all tags to be the same. As clearly documented, libstdc++.so (v3) will bump the major version number just like FreeBSD does on installed shared libraries to express other sorts of C++ compiler or library ABI change. If the system compiler of FreeBSD still wanted to install multiple versions of libstdc++.so (v3) with major number bumps for other reasons (because it is considered safer for compatibility by the system designers), that would be quite fine. But completely ignoring the symbol hiding features will make the FreeBSD C++ system compiler and environment worse than the Linux version and worse than a g++ installed from equivalent FSF sources IMHO (since we will leak all sorts of internal implementation symbols that are not suppose to influence user application link behavior). Anyways, Alex was already going to look into trying this for the FreeBSD 5.0 system compiler so hopefully this will not be the case. Regards, Loren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211130044.gAD0irOo005833>