Hi,

We are trying out nnn with netbsd-curses and musl libc.

The performance results are just awesome!

Seeing the issue https://github.com/jarun/nnn/issues/998 because of the following difference between ncursesw and netbsd-curses:

In a case where ncursesw sends KEY_RESIZE (key value 410) twice, netbsd-curses sends a KEY_RESIZE (key value 512) followed by a NULL (key value 0) character.

nnn uses the NULL key (^Space) for range selection leading into issues.

Can you please take a look why the NULL key is sent after the KEY_RESIZE?

Attached the debug logs from ncursesw and netbsd-curses. A diff would show the problem.

Please let us know if you need some more details.

nnndbg_ncurses.txt nnndbg_netbsd.txt

libtermkey requires strfnames/strnames, which are not currently available in netbsd-curses. The patch was created thanks to the help of Michael Forney.

Best regards, Daniel

diff -urN netbsd-curses.orig/libterminfo/names.awk netbsd-curses/libterminfo/names.awk
--- netbsd-curses.orig/libterminfo/names.awk	Thu Jan  1 00:00:00 1970
+++ netbsd-curses/libterminfo/names.awk	Mon Nov 26 15:26:54 2018
@@ -0,0 +1,21 @@
+/TICODE_[a-z]+,/ {
+	names[++numnames] = substr($1, 8, length($1) - 8)
+}
+
+/^#define t_[a-z]+(t)/ {
+	fnames[++numfnames] = substr($2, 3, length($2) - 5)
+}
+
+END {
+	print "\nconst char *const strnames[] = {"
+	for (i = 1; i <= numnames; ++i)
+		print("\t\"" names[i] "\",")
+	print "\t(void *)0"
+	print "};"
+
+	print "\nconst char *const strfnames[] = {"
+	for (i = 1; i <= numfnames; ++i)
+		print("\t\"" fnames[i] "\",")
+	print "\t(void *)0"
+	print "};"
+}
diff -urN netbsd-curses.orig/libterminfo/term.h netbsd-curses/libterminfo/term.h
--- netbsd-curses.orig/libterminfo/term.h	Mon Nov 26 15:17:58 2018
+++ netbsd-curses/libterminfo/term.h	Mon Nov 26 15:26:00 2018
@@ -1944,6 +1944,8 @@
 #endif
 
 extern TERMINAL *cur_term;
+extern const char *const strfnames[];
+extern const char *const strnames[];
 
 /* setup functions */
 int		setupterm(const char *, int, int *);
diff -urN netbsd-curses.orig/GNUmakefile netbsd-curses/GNUmakefile
--- netbsd-curses.orig/GNUmakefile	Mon Nov 26 16:06:47 2018
+++ netbsd-curses/GNUmakefile	Mon Nov 26 16:08:49 2018
@@ -67,6 +67,7 @@
 TI_SRCS+=libterminfo/compile.c libterminfo/hash.c
 TI_SRCS+=libterminfo/cdbr.c
 TI_SRCS+=libterminfo/mi_vector_hash.c
+TI_SRCS+=libterminfo/names.c
 # Build in termcap emulation
 TI_SRCS+=libterminfo/termcap.c
 TI_LIBA=libterminfo/libterminfo.a
@@ -74,6 +75,9 @@
 TI_OBJS=$(TI_SRCS:.c=.o)
 TI_LOBJS=$(TI_SRCS:.c=.lo)
 TI_MAN =$(sort $(wildcard libterminfo/*.3))
+
+libterminfo/names.c: libterminfo/term.h
+	cat $^ | awk -f libterminfo/names.awk > $@
 
 libterminfo/term.o: CPPFLAGS+=-DINSTALL_PREFIX=\"$(PREFIX)\"
 libterminfo/term.lo: CPPFLAGS+=-DINSTALL_PREFIX=\"$(PREFIX)\"
diff -urN netbsd-curses.orig/libterminfo/GNUmakefile netbsd-curses/libterminfo/GNUmakefile
--- netbsd-curses.orig/libterminfo/GNUmakefile	Mon Nov 26 15:17:58 2018
+++ netbsd-curses/libterminfo/GNUmakefile	Mon Nov 26 15:23:01 2018
@@ -12,6 +12,7 @@
 SRCS+=		compile.c hash.c
 SRCS+=		cdbr.c
 SRCS+=		mi_vector_hash.c
+SRCS+=		names.c
 
 INCS=		term.h
 INCSDIR=	/usr/include
@@ -99,6 +100,9 @@
 
 term.c: compiled_terms.c
 termcap.c: termcap_hash.c
+
+names.c: term.h
+	cat $^ | awk -f names.awk > $@
 
 libterminfo.a: $(OBJS)
 	ar cru $@ $^

• glibc 2.23.90 (gad1b6d8)
• gcc 5.3.0 | clang 3.7.1
• gmake 4.1

Sorry if I'm being dumb here but there seems to be some issue on my system with how includes or conditional macros are defined, as when attempting to build by simply running make I get the following errors:

cc -I../libterminfo -I.. -I. -Werror-implicit-function-declaration    -c -o tic.o tic.c
In file included from /usr/include/sys/stat.h:36:0,
                 from tic.c:33:
/usr/include/time.h:75:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘typedef’
 typedef __time_t time_t;
 ^
/usr/include/time.h:76:1: error: unknown type name ‘__END_NAMESPACE_STD’
 __END_NAMESPACE_STD
 ^
In file included from tic.c:33:0:
/usr/include/sys/stat.h: In function ‘__USING_NAMESPACE_STD’:
/usr/include/sys/stat.h:43:17: error: storage class specified for parameter ‘dev_t’
 typedef __dev_t dev_t;
                 ^
/usr/include/sys/stat.h:48:17: error: storage class specified for parameter ‘gid_t’
 typedef __gid_t gid_t;
                 ^

This continues for roughly 3000 lines before ending with:

/usr/include/sys/stat.h:48:17: error: declaration for parameter ‘gid_t’ but no such parameter
 typedef __gid_t gid_t;
                 ^
/usr/include/sys/stat.h:43:17: error: declaration for parameter ‘dev_t’ but no such parameter
 typedef __dev_t dev_t;
                 ^
tic.c:627:1: error: expected ‘{’ at end of input
 }
 ^
GNUmakefile:27: recipe for target 'tic.o' failed
make: *** [tic.o] Error 1

I don't expect it to really build with glibc but these kinds of errors seem like syntax rules are being broken and I'm not sure where.

libcurses/slk.c: In function '__slk_set': libcurses/slk.c:488:10: error: implicit declaration of function 'wcwidth' [-Werror=implicit-function-declaration] len += wcwidth(wc);

Last known successful build was 22acb33 so something between then and now may be the culprit.

Platform is latest Arch Linux, GCC, GNU crap, etc. Compiling with LDFLAGS=-static, PREFIX="".

It fails with

In file included from libterminfo/setupterm.c:41:0:
/usr/include/curses.h:879:32: error: conflicting types for tparam
 extern NCURSES_EXPORT(char *) tparm (NCURSES_CONST char *, ...); /*special*/

In file included from libterminfo/setupterm.c:41:0:
./libterminfo/term.h:1961:9: note: previous declaration of tparm was here
 char *  tparm(const char *, long, long, long, long, long, 

(Apologies if there is a typo here and there -- I had to type it out manually from a box that doesn't have internet access :( )

It seems to me as if GCC is selecting /usr/include/curses.h over ./curses/curses.h, but the compile options for that module start with -I./../curses, so that seems unlikely.

It could be a smart idea to provide a static-only target inside the GNUMakefile. The default install target can be easily modified with sed(1), but it does not seem to be a perenial solution (for maintainers for example).
I was thinking about something like this:

install-static: install-headers install-stalibs install-progs install-pcs

This is a random (harmless) example (having a all-static could work too). Dunno if it's enough clean for you. I can provide a tiny patch (which is a better) if you agree with the request.

Another question: do you plan to create a tag soon?

The first package that i couldn't compile(thanks to errors) is zsh shell. (and a little note i am a gentoo user, So i am using portage to install packages)

I used this patch: http://ix.io/3uO5 Emerge build log: http://ix.io/3uO6 Emerge configure log: http://ix.io/3uO7

Hello!

I am interested in creating a UEFI application utilizing netbsd-curses. For this purpose, I attempted to build netbsd-curses against gnu-efi on a recent Debian GNU/Linux 11 testing/bullseye amd64 system. (gnu-efi is available as repository package)

However, after adjusting CFLAGS and LDFLAGS accordingly, I found myself unable to successfully link ANY shared library from netbsd-curses. All object files seem to compile flawlessly. I confirmed this by changing parts of the GNUmakefile and forcing some components off, etc.

All attempts to link terminate like this:

cc -I. -I./libterminfo -DHAVE_WCHAR -DINSTALL_PREFIX="/usr" -DINSTALL_PREFIX="/usr" -I./tic -I/usr/include/efi -I/usr/include/efi/x86_64 -I/usr/include/efi/protocol -fno-stack-protector -fPIC -fshort-wchar -mno-red-zone -Wall -DEFI_FUNCTION_WRAPPER -O2 -c -o tic/hash.o tic/hash.c cc -nostdlib -znocombreloc -T /usr/lib/elf_x86_64_efi.lds -shared -Bsymbolic -L /usr/lib /usr/lib/crt0-efi-x86_64.o -lefi -lgnuefi tic/tic.o tic/cdbw.o tic/mi_vector_hash.o tic/compile.o tic/hash.o -o tic/tic /usr/bin/ld: /usr/lib/crt0-efi-x86_64.o: warning: relocation against ImageBase' in read-only section '.text' /usr/bin/ld: /usr/lib/crt0-efi-x86_64.o: relocation R_X86_64_PC32 against symbol 'ImageBase' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status make: *** [GNUmakefile:457: tic/tic] Error 1

I build using the following command:

#!/bin/bash EFIINCS="-I/usr/include/efi -I/usr/include/efi/x86_64 -I/usr/include/efi/protocol" LIB="/usr/lib" EFI_LDS="$LIB/elf_x86_64_efi.lds" EFI_CRT_OBJS="$LIB/crt0-efi-x86_64.o" LDFLAGS="-nostdlib -znocombreloc -T $EFI_LDS -shared -Bsymbolic -L $LIB $EFI_CRT_OBJS -lefi -lgnuefi" CFLAGS="$EFIINCS -fno-stack-protector -fPIC -fshort-wchar -mno-red-zone -Wall -DEFI_FUNCTION_WRAPPER -O2" make CFLAGS="$CFLAGS" LDFLAGS="$LDFLAGS" PREFIX=/usr all-dynamic

From what I can see (I also attempted to force CFLAGS and LDFLAGS into every "CC" line the makefile), all files are built with -fpic. The gnu-efi crt0-efi-x86_64.o was also built with -fpic (to be sure, I also rebuilt it myself).

Do you have any idea what might be causing this issue? If not, do you know an appropriate place where I could ask for help?

Thank you very much! Cheers,

schreiberstein

Attempting a static build. I have a static binutils, musl-libc, and gcc targeted to that libc.

My config.mak (aside, would be nice if build recognized config.mk as well ) looks like:

PREFIX = /home/[me]/repos/toolbox/ins
TARGET = x86_64-linux-musl
CFLAGS=-O2 -I. -I${PREFIX}/${TARGET}/include -I./libcurses -I${PREFIX}/include -nostdinc
LDFLAGS=-static -L${PREFIX}/lib -L${PREFIX}/${TARGET}/lib -nodefaultlibs
CC=${TARGET}-gcc

I then run "make all-static" but it doesn't seem to pull in the LDFLAGS and the build does not build nbperf statically:

file src/netbsd-curses/nbperf/nbperf
src/netbsd-curses/nbperf/nbperf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

It is just after the nbperf build that I get the error which is ( with nbperf's called build command for context )

x86_64-linux-musl-gcc  nbperf/nbperf.o nbperf/nbperf-bdz.o nbperf/nbperf-chm.o nbperf/nbperf-chm3.o nbperf/graph2.o nbperf/graph3.o nbperf/mi_vector_hash.o -o nbperf/nbperf
Generating terminfo hash
TERMINFODIR=./terminfo TOOL_AWK=awk TOOL_NBPERF=nbperf/nbperf TOOL_SED=sed TOOL_SORT=sort TOOL_TIC=tic/host_tic /bin/sh libterminfo/genhash libterminfo/term.h nbperf/nbperf > libterminfo/hash.c
libterminfo/genhash: nbperf/nbperf: /lib/ld-musl-x86_64.so.1: bad ELF interpreter: No such file or directory
make: *** [libterminfo/hash.c] Error 126

Any ideas what could be going on? Also apologies if this is in the wrong place; didn't see anywhere else in the readme to submit a build issue.

Thank you!

Arch. netbsd-curses 0.0.4. Unable to complete the build process due to following error:

In file included from /usr/include/stdlib.h:925:0, from libcurses/fileio.c:41: /usr/include/bits/stdlib.h: In function ‘wctomb’: /usr/include/bits/stdlib.h:90:3: error: #error "Assumed value of MB_LEN_MAX wrong"

error "Assumed value of MB_LEN_MAX wrong"

^~~~~ cc -D_FORTIFY_SOURCE=2 -I. -I./libterminfo -DHAVE_WCHAR -I./libcurses -march=amdfam16 -O2 -pipe -fstack-protector-all -fomit-frame-pointer -Werror-implicit-function-declaration -c -o libcurses/getch.o libcurses/getch.c make: *** [GNUmakefile:399: libcurses/fileio.o] Error 1 make: *** Waiting for unfinished jobs.... ==> ERROR: A failure occurred in build(). Aborting...

How to resolve?

Hi. I'm building tabs from nbase using Clang, and got this error which seems to be related to this ncurses:

/usr/include/curses.h:721:43: error: expected function body after function declarator
int      mvscanw(int, int, const char *, ...) __scanflike(3, 4);
                                              ^
/usr/include/curses.h:731:54: error: expected function body after function declarator
int      mvwscanw(WINDOW *, int, int, const char *, ...) __scanflike(4, 5);
                                                         ^
/usr/include/curses.h:763:31: error: expected function body after function declarator
int      scanw(const char *, ...) __scanflike(1, 2);
                                  ^
/usr/include/curses.h:786:50: error: expected function body after function declarator
int      vw_scanw(WINDOW *, const char *, __va_list) __scanflike(2, 0);
                                                     ^
/usr/include/curses.h:788:49: error: expected function body after function declarator
int      vwscanw(WINDOW *, const char *, __va_list) __scanflike(2, 0);
                                                    ^
/usr/include/curses.h:831:42: error: expected function body after function declarator
int      wscanw(WINDOW *, const char *, ...) __scanflike(2, 3);

A quick grep shows that function was defined in form.h, but adding it didn't solve the problem. And at you said in #46, there's a lot of mismatches growing between NetBSD's version and this version, maybe it caused the problem. What do I need to do make it work?

Hi,

i've spent quite a bit of time trying to debug this issue and at this point i feel confident to say it might be a bug. If putwc is called with a valid codepoint (i've used 0xF6 for testing which should render as "ö") before initscr everything works as expected but anywhere after initscr non 7bit codepoints render as unknown characters (inverse color question marks) and as putwc is used by all functions printing wchar_t strings (for example waddwstr) this basically breaks unicode support. Locale settings (setlocale) don't seem to affect this at all (en_US.UTF-8, C or an invalid setting all result in the same behavior).

Trying to track down the cause i've come to the conclusion that it seems to be related to tputs/ti_puts calls (adding macros to curses_private.h turning those into noops keeps putwc functional but obviously otherwise breaks rendering badly). Sadly i wasn't able to pin this to a certain call as it seems at least multiple (or even all of them?) result in putwc breaking. Any kind of hint or pointer on to how to get this working would be greatly appreciated.

Testing was done on Devuan Ascii (a linux distribution pretty much identical to Debian 9.0 sans systemd). Curses version used is 0.3.2 release. I've also tried a handful of different terminal definitions which made no difference regarding putwc behavior (terminal used for most testing is sakura which is libvte based identifying as xterm-256color. Xterm (the application, not just the definition) gave the same results though.

curses.h is full of identifiers in the __-prefixed namespace, many of which are things that could easily clash with system headers. I saw a report of it failing to build on OSX that looked like it might have been related, and while I didn't see cause for that particular failure it prompted me to notice all these violations. I don't think any of them are essential/public API.

toe - table of (terminfo) entries

With no options, toe lists all available terminal types by primary name with descriptions. File arguments specify the directories to be scanned; if no such arguments are given, your default terminfo direc‐ tory is scanned. If you also specify the -h option, a directory header will be issued as each directory is entered.

# Generate our man pages
terminfo.5: genman terminfo.5.in term.h termcap_map.c
                @echo "Generating terminfo man pages"
                ${SCRIPT_ENV} ${HOST_SH} ${.ALLSRC} > ${.TARGET}

CLEANFILES+=    terminfo.5

man: terminfo.5