Re: cmake needs -ltinfo on Linux

[adr <adr%SDF.ORG@localhost>]

On Fri, 12 Jun 2020, Greg Troxel wrote:

> Date: Fri, 12 Jun 2020 09:16:28 -0400
> From: Greg Troxel <gdt%lexort.com@localhost>
> To: adr <adr%SDF.ORG@localhost>
> Cc: pkgsrc-users%NetBSD.org@localhost
> Subject: Re: cmake needs -ltinfo on Linux
>
> adr <adr%SDF.ORG@localhost> writes:
>
> > that was a hint, not a solution (is not a patch...). I think that
> > you need to add code to detect tinfo on systems with split ncurses.
> > Maybe here?:  mk/curses.builtin.mk
>
> You are welcome to dig in and figure this out.  I don't know what "split
> ncurses means", but in general files like curses.builtin.mk and
> curses.buildlink3.mk attempt to 1) find a sufficient curses and 2) if
> not, depend on pkgsrc curses.  The hard parts are what the interface
> definition of "sufficient" is and coping with all the ways that curses
> might be present.
>
> If there is some library tinfo on some flavor for GNU/Linux that needs
> to be added via bl3 to make sufficient curses available, that might be a
> change.  And if this is how curses is on some GNU/Linux, then upstream
> packages should cope with it.
>
> This is nia's point -- this is complicated and we need to understand
> exactly what step goes wrong and fix it in a sound manner.
>
> I would suggest reading the configure code and looking in
> work/.buildlink to see what is there.

Some linux distributions like the one I'm using here (gentoo),
compile ncurses with some functions in another share object file,
libtinfo.so. Is not a different software package, is ncurses itself.

Cmake check for this lib, but it is not included, so my first
impression was that pkgsrc wasn't making it visible to cmake's
configure process.  But system libraries are supposed to be allways
visible, so that can not be the case.

Linux, cmake, ncurses... I need a tea.

adr.