Re: HEADS-UP: Library version number bumps

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