lkml.org 
[lkml]   [1998]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.050 / U:1.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site