Re: [bug-ncurses] ncurses 6.0 and cur_term function

[Thomas Dickey]

On Mon, Sep 21, 2015 at 10:47:54AM +0200, Dr. Werner Fink wrote:
> On Sun, Sep 20, 2015 at 03:53:01PM -0400, Thomas Dickey wrote:
> > On Sun, Sep 20, 2015 at 06:13:03PM +0200, Ondřej Súkup wrote:
> > > hello,
> > > 
> > > why is in ncurses-6.0:
> > > 
> > > $ readelf -a libncurses.so.6 | grep cur_term
> > > 000000228328  006d00000007 R_X86_64_JUMP_SLO 0000000000000000 
> > > _nc_cur_term + 0
> > >    109: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
> > > address@hidden (24)
> > > 
> > > $ readelf -a libncurses.so.5 | grep cur_term
> > >  000000225f70  003900000006 R_X86_64_GLOB_DAT 0000000000000000 cur_term + > > > 0
> > >     57: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND
> > > address@hidden (29)
> > 
> > Compare with the source code:
> > 
> > > fgrep -n cur_term *.map
> > ncurses.map:879:                cur_term;
> > ncursest.map:344:               _nc_cur_term;
> > ncursest.map:446:               _nc_get_cur_term;
> > ncursest.map:447:               _nc_get_cur_term_sp;
> > ncursestw.map:344:              _nc_cur_term;
> > ncursestw.map:452:              _nc_get_cur_term;
> > ncursestw.map:453:              _nc_get_cur_term_sp;
> > ncursesw.map:186:               cur_term;
> > 
> > For instance, you may be using ncurses 6.0 on OpenSUSE, where they've
> > bent the rules a little to make tinfo the same as for the threaded
> > (libncursest) library.  There are as usual pros/cons about doing that.
> > 
> > (I didn't make it easy to do this, but I didn't make it impossible...)
> 
> Does this mean I should switch over to use several tinfo libraries, one
> for threaded and one for wide+threaded?

As I said, there are pros/cons:

pro:
a) making one tinfo library is doable, and (mostly) reduces the number of
   libraries.
b) functions are bound to the same external symbols.  Global variables are
   not -- they are renamed and wrapped in a macro so that I could enforce
   readonly access to help with mutexes.
c) most applications calling the terminfo level use only the functions.

con:
a) the renaming of global variables isn't (can't be) binary-compatible with
   applications compiled on another platform.
b) applications which attempt to declare those variables for themselves are
   broken either way, but break noticeably when linked with the renamed
   variables.
c) there are a few useful configuration choices (wide/normal, thread/nonthread)
   with variations.  I made it possible (by overriding the choice of map-file)
   to switch between the choices (or even generating a new set of map-files --
   I'm slow -- too many things in progress -- but do intend documenting the
   scripts...).

> On OpenSUSE the libncurses6 is threaded as well as libncursesw6.  IMHO
> it makes no sence to use a third library which is none threaded as this
> will make users more disoriented.
> 
> And what does `bent the rules' mean here? AFAICS and AFAIK the libtinfo
> for both libncurses6 (which is threaded) as wel las libncursesw6 are
> binary comptible.

more/less along the lines of surprising the developer by putting libncursest
in a file that says libncurses

(I don't know offhand, and no one's suggested a better technical solution
for the threaded library interface).

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net

signature.asc
Description: Digital signature