From owner-freebsd-arch Thu Feb 15 1: 3:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 2EECB37B491 for ; Thu, 15 Feb 2001 01:03:54 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1F93rW62243 for ; Thu, 15 Feb 2001 02:03:54 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102150903.f1F93rW62243@harmony.village.org> To: arch@freebsd.org Subject: The whole libc thing. Date: Thu, 15 Feb 2001 02:03:53 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. So what solutions do we have? Green's solution of stealing a pointer and using that to "grow" FILE. This would allow old binaris to keep working at the cost of binary compatibility. There's a few extra indirections in this case, you'll likely not be able to measure that performance loss. But it will work with the case above and most of the others we threw at it. Mike Smith has another solution that I'll let him explain because I don't understand it. It might work, but it might not. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message