This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
[ping][PATCH][BZ #14932] make dlsym return the newest symbol version
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 3 Jun 2013 14:52:06 +0530
- Subject: [ping][PATCH][BZ #14932] make dlsym return the newest symbol version
- References: <20130416082344 dot GD3063 at spoyarek dot pnq dot redhat dot com> <20130419222804 dot EC4F52C08B at topped-with-meat dot com> <20130517073442 dot GG16952 at spoyarek dot pnq dot 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