From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 16:44:01 2004 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 282AC16A4CE for ; Wed, 29 Sep 2004 16:44:01 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5F2A43D53 for ; Wed, 29 Sep 2004 16:44:00 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8ACA851262; Wed, 29 Sep 2004 09:44:22 -0700 (PDT) Date: Wed, 29 Sep 2004 09:44:22 -0700 From: Kris Kennaway To: Thomas Dickey Message-ID: <20040929164422.GA9262@xor.obsecurity.org> References: <20040929030546.GE16305@electra.cse.Buffalo.EDU> <20040929092710.GA59303@cat.robbins.dropbear.id.au> <20040929123100.GA600@electra.cse.Buffalo.EDU> <20040929135217.GA16594@saltmine.radix.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <20040929135217.GA16594@saltmine.radix.net> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: HEADS-UP: Library version number bumps 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: Wed, 29 Sep 2004 16:44:01 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 29, 2004 at 09:52:17AM -0400, Thomas Dickey wrote: > On Wed, Sep 29, 2004 at 08:31:00AM -0400, Ken Smith wrote: > > On Wed, Sep 29, 2004 at 07:27:10PM +1000, Tim Robbins wrote: > > > On Tue, Sep 28, 2004 at 11:05:46PM -0400, Ken Smith wrote: > > > >=20 > > > > >From the "Better late than never" Department... > > > >=20 > > > > It looks like we should probably bump the version of a couple of > > > > the system libraries. With LOTS of help from Kris it looks like > > > > this is the list we think needs a version bump, with the version > > > > from 4.X being placed in compat4x: > > > >=20 > > > > libgnuregex.so.2 > > > > libhistory.so.4 > > > > libm.so.2 > > > > libncurses.so.5 > ....hmmm > > > Why do they need to be bumped? Why use the version from 4.x? It sound= s like > > > this will break a lot of 5.x binaries. > > >=20 > >=20 > > They need to be bumped because the internal workings of the libraries >=20 > that doesn't answer the question (libncurses hasn't changed its interface= for > some time - unless you're stating that the dynamic linker's changed > incompatibly in some fashion). libncurses.so.5 in 5.x does not export many of the global variables exported by 4.x version of libncurses.so.5. The missing symbols are: 23: 0003e270 4 OBJECT GLOBAL DEFAULT 12 SP 166: 0000ee58 26 FUNC GLOBAL DEFAULT 9 _nc_tracebits 170: 00037c0e 2 OBJECT GLOBAL DEFAULT 12 ospeed 175: 00037c2c 4 OBJECT GLOBAL DEFAULT 12 TABSIZE 188: 00036870 4 OBJECT GLOBAL DEFAULT 12 BC 247: 00037744 4 OBJECT GLOBAL DEFAULT 12 COLOR_PAIRS 333: 00037c0c 1 OBJECT GLOBAL DEFAULT 12 PC 370: 00037c1c 4 OBJECT GLOBAL DEFAULT 12 cur_term 406: 00037540 512 OBJECT GLOBAL DEFAULT 12 acs_map 434: 00037748 4 OBJECT GLOBAL DEFAULT 12 COLORS 450: 0003e260 4 OBJECT GLOBAL DEFAULT 12 stdscr 495: 00037c28 4 OBJECT GLOBAL DEFAULT 12 COLS 498: 0003e268 4 OBJECT GLOBAL DEFAULT 12 newscr 515: 0003e264 4 OBJECT GLOBAL DEFAULT 12 curscr 528: 0003686c 4 OBJECT GLOBAL DEFAULT 12 UP 545: 00037c24 4 OBJECT GLOBAL DEFAULT 12 LINES A 4.x binary that calls _nc_tracebits() will fail outright when run on 5.x, but this is a debugging function and not likely to be widely used in the real world, so that isn't a big deal. However, if a 4.x binary sets one of the other variables in the above list expecting it to have some effect on the library (or vice versa, i.e. expects to read the state of the library by accessing the globals), it will not behave the same way when run on 5.x. If I'm mistaken about the implications (perhaps you can guarantee that the above will not happen), please let us know. Kris --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBWuZmWry0BWjoQKURAg3ZAJ0cS2Y98sEkF0xXb0SoOdopSlkjdwCfeHVl 3dC5Yuh+6v2MdxeiZILOmNY= =/kbR -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk--