Re: ANN: ncurses-6.4-20231125

[Dennis Clarke]

On 11/30/23 20:32, Thomas Dickey wrote:
> On Thu, Nov 30, 2023 at 07:44:45PM -0500, Dennis Clarke via Bug 
reports for ncurses, the GNU implementation of curses wrote:
>> On 11/25/23 19:08, Thomas Dickey wrote:
>>> Files:
...
>> Dear Sir :
>>
>>      I see these messages in my email fairly often. I admire the endless
>> maintenance and work that it takes to support a critical library such as
>> ncurses. I am left with a question, something on my mind for some years
>> now, is there a page or document somewhere that explains how to build a
>> good result from these sources? I am going with a guess that a trivial
>> good ol fashioned "./configure --prefix=$SOMEPLACE" would get the job
>> done. However I am just not sure about that.
>
> That's a starting point (which produces static libraries by default).
>
> The INSTALL file in the sources lists all of the configure options.
> I've a web-browsable version of that here:
>
    Thank you for the reply. I was just reading through the INSTALL file
from the source tarball and it seemed fairly clear to me that I could
just easily do this :

e#
e# ./configure --prefix=/opt/bw --with-shared
checking for ggrep... no
checking for grep... grep
checking for egrep... grep -E
Configuring NCURSES 6.4 ABI 6 (Fri Dec  1 00:54:37 GMT 2023)
checking for package version... 6.4
checking for package patch date... 20231125
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
Configuring for linux-gnu
.
.
.

That seems to work like a charm and the compile results in a library for
wide char support :

    ./lib/libncursesw.so.6.4

Then I took a look inside the test directory and gave that a trivial
./configure and make.

So now I have hanoi linked against the wrong libs :

e#
e# ldd hanoi
        linux-vdso.so.1 (0x00007fffb85e1000)
        libncurses.so.6 => /lib/x86_64-linux-gnu/libncurses.so.6 
(0x00007fc658be3000)
        libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x00007fc658bb0000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc658ad1000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc6588f0000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc658c16000)
e#


> Most people use packages that others have built
Something I have plenty of experience with. However I thought it would
be a good idea to try my own toolchain and get the latest ncurses etc.
This has been a real source of education again.

> replacing ncurses on
> your machine can be a source of pain if it's not done right because the
> shell is likely to depend upon it.

My objective is to have a toolchain under /opt/bw that contains most of
the essential bits I need. That means a new bash shell which will be
built after I have readline and ncurses taken care of. I already have
the GCC compiler and a pile of other things built and isolated into that
directory tree.

I get the feeling that I need to install the new ncurses *before* trying
any of the test code bits. That would sort out the location of the libs
and with -Wl,-rpath=/opt/bw/lib,--enable-new-dtags I should have a
decent RPATH in the output ELF files. What bothers me is the terminfo
database and how that is involved.

I am thinking that a trivial guide somewhere would be helpful. If one
decides to build ncurses and readline and also create a new terminfo
database ( directory set ) for an isolated new shell. A shell that has
nothing to do with some package built in some repo from Debian ( or
RedHat etc ) with the added benefit that all of this is able to be
debug single stepped along with gdb if desired.

I will install the new ncurses ( wide? ) and see what happens next.

Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken