From owner-freebsd-current Mon Feb 20 12:28:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA06343 for current-outgoing; Mon, 20 Feb 1995 12:28:04 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id MAA06337 for ; Mon, 20 Feb 1995 12:27:59 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id NAA07242; Mon, 20 Feb 1995 13:31:32 -0700 Date: Mon, 20 Feb 1995 13:31:32 -0700 From: Nate Williams Message-Id: <199502202031.NAA07242@trout.sri.MT.net> In-Reply-To: "Andrey A. Chernov, Black Mage" "Alternate solution for libcompat" (Feb 20, 10:50pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Andrey A. Chernov, Black Mage" , freebsd-current@freefall.cdrom.com Subject: Re: Alternate solution for libcompat Sender: current-owner@FreeBSD.org Precedence: bulk > Look at libcompat structure, it is well separated, > maybe it will be nice to make several libcompats from tree, > i.e. libcompat4.3, libcompat4.4, libregexp, etc. > We easily avoid conflict pointed by nate in this case. Yuck! The purpose of libcompat is to provide *old* interfaces to programs that haven't yet been updated. We are making this *way* more complicated than it needs to be. The current setup w/out the shlib will work, and it's easy to program for and understand. By adding lots of 'compat' libraries it gets very complicated. Also, the programs that need -lcompat *should* be updated to use the newer functions, and by leaving libcompat as the junk library, it let's the programmer who uses them know that those interfaces will go away in the next major revision of the OS. (Ex: FreeBSD 3.0 *grin*) Nate