[Top][All Lists]

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

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

From: Dr. Werner Fink
Subject: Re: Some symbols missed in llib-ltinfo and llib-ltinfot for 6.1?
Date: Fri, 2 Mar 2018 10:58:38 +0100
User-agent: NeoMutt/20170912 (1.9.0)

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

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.

> At the moment I'm working on an improvement to report_offsets to make
> it easier to see these incompatibilities...

It would be perfect if the test suite could be used with some expect(1)
scripts to check out if *some* of the test programs do work.  This
could be used within a build batch job to see if simple things like
the share library dependencies will fail.

  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr

Attachment: signature.asc
Description: PGP signature

reply via email to

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