Messages in this thread | | | Date | Wed, 27 May 1998 15:38:55 +0100 | From | Jamie Lokier <> | Subject | Re: chown(2) vs lchown(2) and application breakage |
| |
On Wed, May 27, 1998 at 02:40:47PM +0200, Andreas Schwab wrote: > Jamie Lokier <lkd@tantalophile.demon.co.uk> writes: > > |> 7. More symbol versioning is used so that an application calling > |> `lchown' in the newer libc can run with an older libc, with > |> the behaviour specified in points 1 and 2. This is optional, > |> it is only needed if we want to support downgrading libc version. > |> It could make the view in the debugger confusing. > > This is impossible with symbol versioning. Older libc's won't have an > lchown entry point, and the dynamic linker cannot change the name of the > reference at runtime. Upward compatibility of libc isn't needed in > general anyway.
I don't actually advocate point 7.
I only mentioned it because someone may wish to downgrade libc for the same reason they may need to downgrade kernel. Namely that the new one doesn't work properly for a while.
Isn't it possible to make link-time `lchown (new libc)' bind to run-time `chown (old version)' when linking with the new libc? I was thinking that maybe in new libc itself, `chown' would have the effect of `lchown' and vice versa, with versioning used to shuffle them at link time. Perhaps also with header file declarations. (Hmm. That _is_ a bad idea isn't it). Hence confusion if viewed in the debugger :-).
-- Jamie
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |