Date: Tue, 12 Nov 2002 22:48:48 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: rittle@labs.mot.com Cc: current@freebsd.org Subject: Re: binutils symbol hiding and versioning (was Re: [PATCH] note the __sF change in src/UPDATING) Message-ID: <3DD1F5D0.590E079E@mindspring.com> References: <3DCADE51.2090607@acm.org> <200211120553.gAC5rQFi093274@latour.rsch.comm.mot.com> <3DD0B80B.2279721@mindspring.com> <200211130044.gAD0irOo005833@latour.rsch.comm.mot.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Loren James Rittle wrote: > > 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. To provide multiple API's in a single shared library image, to avoid a number of images being necessary? That's exactly how it's being used; they call it "age gracefully", but what that means is that multiple API versions remain supported for a very, very long time, without having seperate libraries involved. Technically, the symbol decoration used in C++ is also in error; it's there simply to avoid having to change the object file format to accomodate interface attributes seperately from the symbol name (just as adding an "@@<version name>" suffix does). If this were not ther, the linker could automatically create glue code for doing argument coercion, and it would save a lot of code that currently has to be supplied by programmers. > 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). I'm well aware of how it's used; the IUnknown reference was an analogy; the document you refer to specifically states that it's to avoid a proliferation of shared library files. That's exactly the purpose of IUnknown version information for class factories, as well. Part of the problem here is that GCC dropped the minor version number from shared libraries in binutils, and FreeBSD and Linux followed suit. Now this turns out to be a mistake, and rather than admitting the mistake, instead now we have more decoration occurring in the symbol name to fake up another orthogonal namespace. Traditional UNIX systems have minor versions on shared libraries to address this, and bump major versions only if existing interfaces change, not when interfaces are added (thus program "foo" linked against "lib.so.<M>.<N>" works just fine against "lib.so.<M>.<N+K>"). If you don't like the Microsoft DLL version analogy, a different analogy is the Aztec C support for "directories", by naming files with their complete path, and treating the character "/" as a path component seperator in order to achieve a namespace escape, when the Mac FS didn't support directory hierarchies. In all cases, what's happening is a namespace incursion in order to permit coexistance of otherwise conflicting implementations. > 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. This still fails when the OS version does not bump each time the compiler version bumps. I guess this is OK, if you are a compiler vendor, but less OK, when you are an OS vendor. 8-). > 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. No, it will make it incompatible, which is rather annoying, but it's an introduced incompatability that came from the compiler, and we shouldn't pretend it isn't. In any case, the issue was in attempting to prevent the exposure of data interfaces, and symbols not part of the defined API; this is still goinf to cause problems for the reasons this discussion came up in the first place: other language compilers that need to link against system libraries, and share implementation instances so that they can be linked against foreign object files that use the same underlying implementation. For the purposes of this discussion, that's the stdio implementation, as exposed in the FORTRAN 95 and Modula 3 compilers (non-GNU compilers, incapable of implementing symbol decoration without substantial modification). The reason for the current discussion was hiding of implementation details, using the symbol-hiding facilities. Implementing symbol versioning, instead, fails to hide the symbols that are created as part of the implementation details. And that's still evil(tm). -- Terry 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?3DD1F5D0.590E079E>