This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
[ping2][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, 10 Jun 2013 14:07:49 +0530
- Subject: [ping2][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> <20130603092206 dot GK2145 at spoyarek dot pnq dot redhat dot com>
Ping!
On Mon, Jun 03, 2013 at 02:52:06PM +0530, Siddhesh Poyarekar wrote:
> 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