Re: HEADS-UP: Library version number bumps
From: Thomas Dickey (dickey_at_radix.net)
Date: 09/29/04
- Previous message: kama: "Re: if_bge with <Broadcom BCM5703 Gigabit Ethernet, ASIC rev.0x1002> (was: Re: Strange things on GBit / 1000->100 / net.inet.tcp.inflight.* )"
- In reply to: Kris Kennaway: "Re: HEADS-UP: Library version number bumps"
- Next in thread: Thomas Dickey: "Re: HEADS-UP: Library version number bumps"
- Reply: Thomas Dickey: "Re: HEADS-UP: Library version number bumps"
- Reply: Kris Kennaway: "Re: HEADS-UP: Library version number bumps"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 29 Sep 2004 13:16:19 -0400 To: freebsd-current@freebsd.org
On Wed, Sep 29, 2004 at 09:44:22AM -0700, Kris Kennaway wrote:
>
> 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
Something is going wrong with your script, since most of those are
well-defined symbols that are present in the normal and wide-character
libraries. (None are functions, all are variables).
** If the script is blameless, then there's a change in the way the
** linker builds shared libraries (the point I was trying to establish).
The wide-character library uses a macro for acs_map (but then, we're not
talking about that ;-).
The only other one that is noticeable is the private _nc_tracebits
symbol (not the topic of this discussion, since applications that use
private symbols aren't supported by anyone that I recall).
> 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.
_nc_tracebits is a variable, not a function. You can't "call" it.
Also - checking the changelog - _nc_tracebits was not in ncurses 4.2
(it was introduced in late 1998).
> 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
-- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
- application/pgp-signature attachment: stored
- Previous message: kama: "Re: if_bge with <Broadcom BCM5703 Gigabit Ethernet, ASIC rev.0x1002> (was: Re: Strange things on GBit / 1000->100 / net.inet.tcp.inflight.* )"
- In reply to: Kris Kennaway: "Re: HEADS-UP: Library version number bumps"
- Next in thread: Thomas Dickey: "Re: HEADS-UP: Library version number bumps"
- Reply: Thomas Dickey: "Re: HEADS-UP: Library version number bumps"
- Reply: Kris Kennaway: "Re: HEADS-UP: Library version number bumps"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]