Re: chown(2) vs lchown(2) and application breakage

Jamie Lokier (lkd@tantalophile.demon.co.uk)
Wed, 27 May 1998 15:38:55 +0100

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