From owner-freebsd-current@FreeBSD.ORG Sat Nov 8 16:13:10 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0194D16A4D0 for ; Sat, 8 Nov 2003 16:13:10 -0800 (PST) Received: from smtp.mho.com (smtp.mho.net [64.58.4.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 3023243FDD for ; Sat, 8 Nov 2003 16:13:08 -0800 (PST) (envelope-from scottl@freebsd.org) Received: (qmail 14200 invoked by uid 1002); 9 Nov 2003 00:13:05 -0000 Received: from unknown (HELO freebsd.org) (64.58.1.252) by smtp.mho.net with SMTP; 9 Nov 2003 00:13:05 -0000 Message-ID: <3FAD8667.4040700@freebsd.org> Date: Sat, 08 Nov 2003 17:12:23 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031103 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Kennaway References: <20031107043223.GA4374@rot13.obsecurity.org> In-Reply-To: <20031107043223.GA4374@rot13.obsecurity.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: Another 5.2 todo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2003 00:13:10 -0000 Kris Kennaway wrote: > libm has been fixed, but there are several other libraries that either > need to get the same treatment or have their major version number > bumped. > > See the attached mail. > > Kris > Robert has offered to take care of libutil. We need someone to help figure out the right approach for libncp and libopie. I'm tempted to just bump their versions, but I'll wait for better wizdom from the community first. Can anyone comment here? > > ------------------------------------------------------------------------ > > I audited the results of my comparison script to look for other cases > of symbols being added to 5.x versions of libraries that have the same > version in 4.x, which do not resolve within this set of common > libraries. Here are the results: > > ==> Comparing symbols in libisc.so.1 > * pselect > > Called from evGetNext(), which exists in 4.x's libisc. Perhaps libisc > is not widely used except for BIND applications. > > ==> Comparing symbols in libm.so.2 > * __fpclassifyd > * __fpclassifyf > > Used in scalb() and scalf(), which exist on 4.x. > > ==> Comparing symbols in libncp.so.1 > * _getprogname > > This is used in 5.x's ncp_getopt() and ncp_error() functions, which > also exist on 4.x. > > ==> Comparing symbols in libopie.so.2 > * __xuname > > This is hidded inside the static uname() implementation in > and is referenced from opieinsecure() and > opienewseed(), which exist on 4.x. > > ==> Comparing symbols in libutil.so.3 > * __pw_scan > > This one is OK because it is only used from pw_scan(), which does not > exist on 4.x. > > * _time_to_time32 > > This is called from logout() on 5.x, which is a function also used in > 4.x's libutil. For example, the following test application > demonstrates the breakage: > > #include > #include > > main() { > logout("ttypa"); > } > > It runs correctly as root on 4.x, but gives the following as root on 5.x: > > root@rot13:/home/kkenn /tmp/a > /usr/libexec/ld-elf.so.1: /usr/lib/libutil.so.3: Undefined symbol "_time_to_time32" > > * mac_free > * mac_from_text > * mac_is_present > * mac_set_proc > > These are called from setusercontext(), and might cause runtime > failures if a 4.x binary that uses setusercontext() is run on a 5.x > system that has MAC enabled. > > Kris