I have tried as the title has said with the latest binary package and from compiling on linux source via gentoo.
Binary looks for a wide ncurses lib, which exists, and also the source code.
Seems you just need to link in 'tinfow' for people who may have both and may confuse the compiler.
gdb hinted at this, and then ldd. So it works when compiled on a system with both actual sets of ncurses and ncursesw
along with tinfo and tinfow. Has been running for about a week now and still seems to behave normally. One of these days
I'll actually read and reply to the QWK packets and hopefully have a good time. <-DaRKLoRD BBS=-
You will have to come up with an if type check of some kind since 'uname -s' just will say 'Linux' on gentoo, but is an easy fix.
Fix:
# OS-specific: terminal implementation and link flags. Switched from linking tinfo to tinfow for Gentoo -Darksix 2026
ifeq ($(UNAME_S),Linux)
TERM_SRC = $(SRCDIR)/terminal_ncurses.cpp
CXXFLAGS += -D_XOPEN_SOURCE_EXTENDED
LDFLAGS = -lncursesw -ltinfow
endif
``` Makefile:
My uname wouldn't show up gentoo though no matter how with my custom kernels. Should work on normal gentoo with a grep of gentoo in kernel name with ($UNAME_A).gentoo) probably..
I have tried as the title has said with the latest binary package and from compiling on linux source via gentoo.
Binary looks for a wide ncurses lib, which exists, and also the source code.
Seems you just need to link in 'tinfow' for people who may have both and may confuse the compiler.
gdb hinted at this, and then ldd. So it works when compiled on a system with both actual sets of ncurses and ncursesw
along with tinfo and tinfow. Has been running for about a week now and still seems to behave normally. One of these days
I'll actually read and reply to the QWK packets and hopefully have a good time. <-DaRKLoRD BBS=-
You will have to come up with an if type check of some kind since 'uname -s' just will say 'Linux' on gentoo, but is an easy fix.
Fix: