Re: Some symbols missed in llib-ltinfo and llib-ltinfot for 6.1?

[Sven Joachim]

Am 02.03.2018 um 10:58 schrieb Dr. Werner Fink:

> On Thu, Mar 01, 2018 at 10:37:21AM -0500, Thomas Dickey wrote:
>> On Thu, Mar 01, 2018 at 08:09:17AM +0100, Dr. Werner Fink wrote:
>> > On Wed, Feb 28, 2018 at 05:48:15PM +0000, Sven Joachim wrote:
>> > > Am 28.02.2018 um 12:35 schrieb Dr. Werner Fink:
>> > > 
>> > > > On Tue, Feb 27, 2018 at 09:18:04PM +0000, Thomas Dickey wrote:
>> > > >> b) link everything against "ncurseswt"
>> > > >
>> > > > That means enforce every package to use the libncursew/libtinfow ?
>> > > > At least all python3 and its modules could be an option
>> > > 
>> > > Or, alternatively, configure libncursesw with "--with-termlib=tinfo" and
>> > > install the same tinfo library for the wide and non-wide configurations,
>> > > getting rid of libtinfow entirely.  This is what Fedora and Debian do.
>> > 
>> > This I had done the last twenty years and run into a problem where last
>> > year libtinfo and libtinfow become binary distinct resulting in a huge
>> > number of bugs as every program using libncursesw had crashed
>> 
>> I recall fixing more than one problem of that nature, but don't
>> recall it being delayed and (since the fixes are easily backported)
>> don't see it as a reason to not do as Sven suggests.
>
> Hmmm ... I see two problems, first the libtinfo of the wide configuration
> has to be used as otherwise _nc_copy_termtype2, _nc_export_termtype,
> _nc_fallback2, _nc_free_termtype2, and _nc_read_entry2 will be missed.
> Could be solved by correct order of the builds as well as with a sanity
> check.

Basically that's what I did in Debian where we used to package libtinfo
from the non-wide build too.

> But how to avoid a recompile of the full distribution and third party
> programs? Only an auxiliary filter shared lib AFAIK or similar could be
> helpfull to fulfill the existing libtinfow dependencies.

Doesn't a simple symlink from libtinfo.so.6 to libtinfow.so.6 do the
trick?

Cheers,
       Sven