From owner-freebsd-hackers Mon Feb 27 07:12:13 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id HAA26576 for hackers-outgoing; Mon, 27 Feb 1995 07:12:13 -0800 Received: from deacon.cogsci.ed.ac.uk (deacon.cogsci.ed.ac.uk [129.215.144.7]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id HAA26524; Mon, 27 Feb 1995 07:11:05 -0800 Received: (from richard@localhost) by deacon.cogsci.ed.ac.uk (8.6.10/8.6.9) id PAA13996; Mon, 27 Feb 1995 15:09:34 GMT Date: Mon, 27 Feb 1995 15:09:34 GMT Message-Id: <199502271509.PAA13996@deacon.cogsci.ed.ac.uk> From: Richard Tobin Subject: Re: Binary compatibility with NetBSD To: "Jordan K. Hubbard" In-Reply-To: Jordan K. Hubbard's message of Sat, 25 Feb 1995 09:28:42 -0800 Organization: just say no Cc: freebsd-hackers@freefall.cdrom.com Sender: hackers-owner@FreeBSD.org Precedence: bulk I'm a little surprised by the responses to my message about shared library compatibility. I didn't expect that it would be possible to have the same shared libraries as NetBSD, though some people seem to be suggesting it. My idea was rather that you could install the NetBSD shared libraries, and use them. This is (if I understand correctly) how system V compatibility works. As Bruce pointed out, the combination of dynamic application + libraries is much the same as a static application, and Jordan at least seems to believe that static compatibility can be maintained. So I don't understand why Jordan thinks it would be so hard; in particular I don't understand the comment that "it's easily broken (meaning you get stuck in this thankless loop of fixing it over and over again as the libraries themselvse change)". Why would anything have to be done when the libraries change (apart from installing the new ones, of course)? Changes would only be needed when the interface between ld.so and the libraries changed, which shouldn't be very often. Just to re-iterate, my suggestion is to (a) make ld.so compatible and (b) have something in the executable to indicate which libraries it was linked against. Then ld.so would link against the appropriate ones at run-time. Is there some fatal flaw in this? If so, what is it? Finally, if BSDI's shared library scheme is substantially different, it should be much *easier* be compatible, since the big problem with NetBSD compatibility is the difficulty of distinguishing between binaries - the systems are too similar. Of course, the BSDI shared libraries may not be freely distributable, which would remove most of the value of this. -- Richard