Date: Wed, 29 Sep 2004 09:44:22 -0700 From: Kris Kennaway <kris@obsecurity.org> To: Thomas Dickey <dickey@radix.net> Cc: freebsd-current@freebsd.org Subject: Re: HEADS-UP: Library version number bumps Message-ID: <20040929164422.GA9262@xor.obsecurity.org> In-Reply-To: <20040929135217.GA16594@saltmine.radix.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040929164422.GA9262>