[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ugly tinfo ABI problem

From: Thomas Dickey
Subject: Re: ugly tinfo ABI problem
Date: Tue, 18 Jan 2005 06:39:37 -0500 (EST)

On Mon, 17 Jan 2005, Stanislav Ievlev wrote:

In current snapshot libtinfo and libtinfow are binary incompatible,
because structures "screen" and "SLK" use NCURSES_CH_T type.

(having had some time to recall the pieces, I see why it's not a problem).

The struct's declared in curses.priv.h are all secrets of libncurses and its variations. They're passed around as pointers; the application cannot (unless it includes curses.priv.h, which is against the rules) know the size of these. So the ABI hasn't changed. I've made several changes over the past 4-5 years within those guidelines.

The same would not apply to WINDOW - historically it has been public. That's why adding to it is more complicated: applications could be storing WINDOW structs and know about their size, and some features such as getyx() know about offsets within the struct. To add the bits I need, I have to put additional information on the end, and (as noted) bump the ABI to 6. That much is in the configure script.

ABI 6 applies only to this experimental feature. The new feature does not yet do anything in the patches that I've merged, since I'm still working on the details within addch() to make it function properly. Until I get that far, I'll merge in pieces which (I think) do not modify the existing ABI or functionality (and as usual, bugs in that process should be reported).

In our distribution (ALT Linux) we are using scheme with separate tinfo as a
replacement of libtermcap (shared library ncurses + shared library tinfo).
So we have an applications that use libtinfo library only.

So in unicode enviroment we will have two version of tinfo library. Some
of applications will be linked with libtinfow, and others with libtinfo.

We supports both unicode and non-unicode enviroments, so we will have a big

Why "terminal information" library depends on build type: widechar or
"libtinfo" must be a replacement of "libtermcap",but it will not be such
replacement until ABI problem above exist.

Could you fix it?

With best regards
Stanislav Ievlev

ALT Linux Team.

Bug-ncurses mailing list

Thomas E. Dickey

reply via email to

[Prev in Thread] Current Thread [Next in Thread]