From owner-freebsd-current Tue Nov 12 16:44:59 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA27937B401 for ; Tue, 12 Nov 2002 16:44:56 -0800 (PST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F9F143E4A for ; Tue, 12 Nov 2002 16:44:56 -0800 (PST) (envelope-from rittle@latour.rsch.comm.mot.com) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id gAD0fpUH023078; Tue, 12 Nov 2002 17:41:52 -0700 (MST) Received: [from latour.rsch.comm.mot.com (latour.rsch.comm.mot.com [145.1.80.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id RAA05623; Tue, 12 Nov 2002 17:44:54 -0700 (MST)] Received: from latour.rsch.comm.mot.com (localhost.rsch.comm.mot.com [127.0.0.1]) by latour.rsch.comm.mot.com (8.12.6/8.12.6) with ESMTP id gAD0irdF005836; Tue, 12 Nov 2002 18:44:53 -0600 (CST) (envelope-from rittle@latour.rsch.comm.mot.com) Received: (from rittle@localhost) by latour.rsch.comm.mot.com (8.12.6/8.12.6/Submit) id gAD0irOo005833; Tue, 12 Nov 2002 18:44:53 -0600 (CST) Date: Tue, 12 Nov 2002 18:44:53 -0600 (CST) From: Loren James Rittle Message-Id: <200211130044.gAD0irOo005833@latour.rsch.comm.mot.com> To: tlambert2@mindspring.com Cc: current@freebsd.org In-reply-to: <3DD0B80B.2279721@mindspring.com> (message from Terry Lambert on Tue, 12 Nov 2002 00:12:59 -0800) Subject: Re: binutils symbol hiding and versioning (was Re: [PATCH] note the __sF change in src/UPDATING) Reply-To: rittle@labs.mot.com References: <3DCADE51.2090607@acm.org> <200211120553.gAC5rQFi093274@latour.rsch.comm.mot.com> <3DD0B80B.2279721@mindspring.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <3DD0B80B.2279721@mindspring.com>, Terry Lambert 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