From owner-freebsd-arch  Thu Feb 15  6:17:22 2001
Delivered-To: freebsd-arch@freebsd.org
Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3])
	by hub.freebsd.org (Postfix) with ESMTP id AD2A837B491
	for <arch@FreeBSD.ORG>; Thu, 15 Feb 2001 06:17:19 -0800 (PST)
Received: (from eischen@localhost)
	by pcnet1.pcnet.com (8.8.7/PCNet) id JAA02146;
	Thu, 15 Feb 2001 09:16:48 -0500 (EST)
Date: Thu, 15 Feb 2001 09:16:47 -0500 (EST)
From: Daniel Eischen <eischen@vigrid.com>
To: Warner Losh <imp@harmony.village.org>
Cc: arch@FreeBSD.ORG
Subject: Re: The whole libc thing.
In-Reply-To: <200102150903.f1F93rW62243@harmony.village.org>
Message-ID: <Pine.SUN.3.91.1010215091552.2023A@pcnet1.pcnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Thu, 15 Feb 2001, Warner Losh wrote:
> 
> OK.  Pere's bumping of libc won't work.  We'd have to bump all shared
> libraries that use stdio, which is too many.  Even in the ports
> system.
> 
> The issue, for those following along at home.
> 
> libc.so.5 defined std{in,out,err} in terms of absolte offsets into
> the __sF array.  This is bad if we ever want to change the size of
> __sF.
> 
> libc.so.5.20010213 introduced __std{in,out,err} to deal with this.
> These would be referenced rather than the __sF array.
> 
> Now here's where the problem comes in.
> 
> If I rebuild the world, certain libraries, like libcam.so.2, change
> from referencing __sF to referencing __stderr and the like.  This is
> fine for new binaries, but introduces a problem for old binaries.
> 
> Consider cdrecord built before the change, say on 4.2R.  It will
> reference libc.so.4 (which has the __sF symbols, but not the __stderr
> ones) and libcam.so.2.  After the above buildworld, running cdrecord
> will break with __stderr undefined.  why?  Well, that's involved.
> 
> cdrecord runs and ld.so brings in libcam.so.2 and libc.so.4.  Since
> libcam.so.2 references __stderr and libc.so.4 doesn't have it, we get
> the error.
> 
> The only solution is to bump the major number of libcam.so.3 so that
> old applications continue to work.
> 
> However, that's the rub.  *ALL* libraries that reference
> std{in,out,err} would need their major numbers bumped.

Let's just bump the libraries and be done with it.

-- 
Dan Eischen


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message