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: Roland McGrath <roland at hack dot frob dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 19 Apr 2013 15:28:04 -0700 (PDT)
- Subject: Re: [PATCH][BZ #14932] make dlsym return the newest symbol version
- References: <20130416082344 dot GD3063 at spoyarek dot pnq dot redhat dot com>
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.
None of that really helps you resolve the issue you asked about.
But it gives you an idea of how little hope you should have. ;-)
Thanks,
Roland