Date: Fri, 16 Oct 1998 00:22:39 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: julian@whistle.com (Julian Elischer) Cc: tlambert@primenet.com, info@highwind.com, lists@tar.com, current@FreeBSD.ORG Subject: Re: Recent 3.0's are Depressing Message-ID: <199810160022.RAA29939@usr04.primenet.com> In-Reply-To: <Pine.BSF.3.95.981015171055.6253G-100000@current1.whistle.com> from "Julian Elischer" at Oct 15, 98 05:11:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Apparently the newest libc's have been fixed to cope with whatever was > changed. (or it was changed back). Latest reports have it working again. > > > > > Both of us are on the "latest" libc_r and we see different results. > > > Statically linking an old libc_r into the application didn't fix > > > the problem. This is possible. But I am unconvinced, since the "it's working" report was on a kernel and libc_r combination from 11 Oct 1998. We need to get a hard date for the problem start, with kernel source dates, before we can say the problem no longer exists. I'm also concerned that, even if it's a libc_r/kernel mismatch, this bodes poorly for statically linked libc_r applications, such as the one Highwind is distributing. It would be a bad precedent to set to not attempt to ensure binary backward compatability because "it's just libc_r". On the other hand, I would probably welcome such a precedent, since it would mean that making FreeBSD's default ABI IABI compliant would be possible, and then we could take advantage of all of the existing Solaris x86 and UnixWare applications without having to ...uh, borrow... shared libraries off a Solaris or SCO box. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810160022.RAA29939>