[ping][PATCH][BZ #14932] make dlsym return the newest symbol version

[Siddhesh Poyarekar <siddhesh at redhat dot com>]

Ping!

On Fri, May 17, 2013 at 01:04:42PM +0530, Siddhesh Poyarekar wrote:
> On Fri, Apr 19, 2013 at 03:28:04PM -0700, Roland McGrath wrote:
> > I don't recall paying attention to that issue at the time.
> > Perhaps AJ will recall something about it.
> > 
> > Just from looking at the cited 1999 thread, I understand the concern
> > that Geoff Keating was raising at the time.  I don't think it was so
> > much a statement that the existing behavior was intentional, but just
> > a statement that there is no answer that doesn't have some potential
> > downside.  Really what it boils down to is that using dlsym (vs
> > dlvsym) at all is essentially always wrong when the object being
> > interrogated uses (or is not known not to use) symbol versioning.
> > 
> > The simple fact is that we don't know how many applications are
> > (presumably unwittingly) depending on the old behavior and would be
> > broken by a change, nor how many applications are presently broken and
> > would be fixed by the change.  The closest we have to a way to be
> > right about that is to introduce a new symbol version for dlsym so
> > that old binaries get the old behavior.  But even that's not too
> > likely to avoid application problems, because people just recompiling
> > an old application probably have no idea which of the behaviors it
> > implicitly expects.
> > 
> > There isn't even a very good answer to what the user code ought to be
> > doing instead to avoid the whole problem.  It can use dlvsym, but that
> > presupposes that it actually knows what symbol version to ask for.  At
> > the time you compile a particular program or library, you can know
> > this for the moment.  But there is no one thing you can write in the
> > source code that will still be right after a future recompilation.
> > (That is, unless you do something like roll your own configure check
> > to determine the current default version at build time.)  We could
> > conceivably make this easier in the future by doing something like
> > generating a header file akin to gnu/lib-names.h that defines a macro
> > for each and every public symbol in each library.
> 
> I think the core problem I'm trying to fix is the inconsistency in
> dlsym behaviour, where it returns the latest version for all handles
> except RTLD_NEXT.
> 
> Making this behaviour consistent is the best way forward IMO.  If one
> wants an older symbol, the correct way is in fact to use dlvsym to ask
> for the specific version.  Any application depending on the current
> behaviour is depending on a bug, not a documented feature.
> 
> Siddhesh