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: Mon, 10 Jun 2013 16:12:42 -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> <20130419222804 dot EC4F52C08B at topped-with-meat dot com> <20130517073442 dot GG16952 at spoyarek dot pnq dot redhat dot com>
> 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.
The point I made earlier is that any application depending on *any* use
of dlsym with a symbol that might be versioned is depending on details
that are not guaranteed in the face of library upgrades, and thus is
essentially buggy already. So any application that would be fixed by
your change is itself doing something just as suspect as is any
application that would be broken by your change.
The consistency argument is certainly sensible on its own terms. But
since it doesn't make the situation actually sane, and it does perturb a
situation that is already very subtle and thoroughly insane, it's not a
safely conservative change to make. In some such cases, it is
appropriately conservative to define a new symbol version that has the
new behavior so that freshly-built programs get a more defensible set of
behaviors while existing binaries are not perturbed. I would not have a
very strong argument against your change if you did it that way. But
I'm not really in favor of it either and won't be in favor of anything
that perturbs the status quo without providing a new correct option for
applications to do something that is not insane.
Thanks,
Roland