Re: HEADS-UP: Library version number bumps

From: Kris Kennaway (kris_at_obsecurity.org)
Date: 09/29/04

  • Next message: Thomas Dickey: "Re: HEADS-UP: Library version number bumps" 
    Date: Wed, 29 Sep 2004 10:27:21 -0700
To: Thomas Dickey <dickey@radix.net>

    On Wed, Sep 29, 2004 at 01:16:19PM -0400, Thomas Dickey wrote:
    > 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).

    OK, I think my script is confused because objdump thinks the symbols
    moved from .data to .bss. I'll take a closer look (and switch it over
    to use readelf instead).

    > 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.

    The linker, curs_trace(3) and <curses.h> beg to differ:

    extern char *_nc_tracebits(void);

    > Also - checking the changelog - _nc_tracebits was not in ncurses 4.2
    > (it was introduced in late 1998).

    We're not talking about ncurses 4.2, as I tried to clarify in my
    previous email.

    Kris

  • Next message: Thomas Dickey: "Re: HEADS-UP: Library version number bumps"