Date: Tue, 14 Nov 2000 15:56:11 -0800 From: "David O'Brien" <obrien@freebsd.org> To: Satoshi - Ports Wraith - Asami <asami@freebsd.org> Cc: stable@freebsd.org Subject: Re: libc shlib version Message-ID: <20001114155611.A94037@dragon.nuxi.com> In-Reply-To: <vqcwve6td2i.fsf@silvia.hip.berkeley.edu>; from asami@freebsd.org on Tue, Nov 14, 2000 at 02:15:49PM -0800 References: <31309.974061923@winston.osd.bsdi.com> <200011130413.eAD4DKj41211@vashon.polstra.com> <vqcd7g09vtq.fsf@silvia.hip.berkeley.edu> <200011131727.eADHR8c42388@vashon.polstra.com> <vqc8zqnmqkb.fsf@silvia.hip.berkeley.edu> <20001113153325.D39667@dragon.nuxi.com> <20001114081845.A76050@dragon.nuxi.com> <vqcwve6td2i.fsf@silvia.hip.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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/<arch>/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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001114155611.A94037>