Date: Sat, 30 Jul 2016 10:09:08 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Daniel Eischen <deischen@freebsd.org> Cc: Ed Schouten <ed@nuxi.nl>, "freebsd-arch@freebsd.org" <arch@freebsd.org>, Ed Maste <emaste@freebsd.org> Subject: Re: lib/libc/Versions.def: new symbol version for 12.x Message-ID: <20160730070908.GM83214@kib.kiev.ua> In-Reply-To: <4647100A-67D9-416D-8E34-4CC1F450227A@freebsd.org> References: <CABh_MKnZkd3U0jV07idrpHqaniZvzUbhnSHz3BpAAKOi7d807Q@mail.gmail.com> <Pine.GSO.4.64.1607291445570.11109@sea.ntplx.net> <CAPyFy2DymK8g3V357f7WbedD3qXbabcN3=d3vGNJWFcBQ6cNbQ@mail.gmail.com> <CABh_MK=cLNrCiVEKdCHxicaJj6dGGyRw4KDEwY5bJuDp2tXcVA@mail.gmail.com> <4647100A-67D9-416D-8E34-4CC1F450227A@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 29, 2016 at 05:37:00PM -0400, Daniel Eischen wrote: > They were originally modeled similar to Solaris (and Linux to some extent, IIRC): > > https://docs.oracle.com/cd/E19683-01/806-4125/solarisabi-8/index.html > > I think there's not much point of changing the naming scheme now, it's not like it's visible to the typical user. The comment in the Version.defs file pretty much explains everything. What we have currently in the symbol versioning scheme definitely has nothing common with Solaris, and has only slight resemblance to the glibc variant. Our rtld implements the GNU extention of the original Solaris versioning, but the way we provide actual versioning in shipped libraries defeats some useful parts of the functionality. The original Solaris scheme, AFAIR, has the goal of preventing binary linked to a newer library, even to try to start with the older version of the library. Solaris libc, when introducing a new symbol, also added a new version to the list of versions implemented by the library. On startup, dynamic linker verifies that all referenced versions are present in the library. This is needed since default binding resolution is lazy, and missed symbol goes undetected until called. As result, applications fail hard somewhere at runtime, surprising users and corrupting data, unless checked. We do exactly opposite, all symbols added during the CURRENT-X development cycle, are added into single namespace. This would be not too bad, we do not care much about CURRENT ABI until it is backward compatible, but we also merge symbols to stable branches under same namespace. The result is that you cannot distinguish older and newer libraries from the same stable branch at the startup linking. >From what I remember, both Solaris and glibc create new namespace for each symbols addition. GNU scheme has more flexibility by allowing to change ABI of symbols, and this is the only feature we use in limited form (we cannot provide ABI compat shims for symbols which change more than once during one CURRENT cycle). IMO it does not make sense to change current scheme without fixing the bug I described above. Any change in naming makes the things even more confusing, and imposing the pain only for somebody aestetic feel does not look right.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160730070908.GM83214>