From owner-freebsd-stable Tue Nov 14 15:56:15 2000 Delivered-To: freebsd-stable@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 3A71237B4CF; Tue, 14 Nov 2000 15:56:12 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id PAA94164; Tue, 14 Nov 2000 15:56:11 -0800 (PST) (envelope-from obrien) Date: Tue, 14 Nov 2000 15:56:11 -0800 From: "David O'Brien" To: Satoshi - Ports Wraith - Asami Cc: stable@freebsd.org Subject: Re: libc shlib version Message-ID: <20001114155611.A94037@dragon.nuxi.com> Reply-To: stable@freebsd.org References: <31309.974061923@winston.osd.bsdi.com> <200011130413.eAD4DKj41211@vashon.polstra.com> <200011131727.eADHR8c42388@vashon.polstra.com> <20001113153325.D39667@dragon.nuxi.com> <20001114081845.A76050@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from asami@freebsd.org on Tue, Nov 14, 2000 at 02:15:49PM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 14, 2000 at 02:15:49PM -0800, Satoshi - Ports Wraith - Asami wrote: > Hmm. That's a good point. So you mean there is no way to build a > libc that works for 4.2 that will also work with a 4.0 kernel? Yes. > (I don't think just changing the libc source on a 4.0 machine will > accomplish that. Besides, that sounds even more dangerous, to build > something with mixed sources.) IF 4.2-R libc sources would compile on a 4.0-R system the resulting libc.so.4 will work much better than using a stock 4.2-R libc.so.4. This is because the /usr/include/sys/ and /usr/include/machine/ headers (especially the syscall ones) used to compile the 4.2-R libc sources will match the 4.0-R kernel. Interface changes (as exposed) in /sys/sys and /sys//include are one of the bigger ways to get a kernel and userland out of sync. > However, incompatible is incompatible and it seems to me that we should > still bump the version of libc just to make sure people won't get into > a similar situation by copying supposedly compatible shared library. Maybe.... but this is unix where we kinda give people all the rope the need... Switching to a versioned API would probably help this issue. But it increases the library and toolchain maintenance. > (If libc was at so.5 in the upgrade kit it at least wouldn't have > killed existing binaries.) I guess that would be one approach... but I fear it will lead us to bump the version at every release. I think this could increase support questions. > By the way, if the conclusion is that we can't provide an upgrade kit > that will work for 4.0R (regardless of whether we bump libc or not), > I'll just replace that package with something that prints "sorry, we > can't support that system anymore, please upgrade". If you've got space [and time] to build a special libc.so.4 for 4.[01]-R, using 4.2 libc (only) sources, it should work well. Of course at some point it is a hopeless cause, as there will be some change to the libc sources that requires changes in /usr/include/{sys,machine}/ . In the merging of xpg4 into libc using the various Binutils utils. JDP would know more about the viability of this than I do. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message