This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [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: Fri, 17 May 2013 13:04:42 +0530
- Subject: Re: [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>
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