I don't know if it was the last update to ncurses or an earlier one, but the port devel/adacurses builds with base ncurses on FreeBSD 8,9,10 but not 11: http://beefy2.isc.freebsd.org/bulk/head-amd64-default/2015-03-19_00h08m00s/logs/errors/adacurses-20110404_3.log The port was previously using ncurses from ports, so the failures started after switching to base ncurses. Can somebody tell me if there is an unintended regression on base, or if adacurses simply requires ncurses from ports now?
Adding the two developers involved with last update to ncurses in base.
It turns out that I did have FreeBSD 11 (from October 2014), and the problem was there then. on FreeBSD 9: > # grep is_keypad /usr/lib/libncurses.so > binary file /usr/lib/libncurses.so matches on FreeBSD 11: nothing returns on FreeBSD 9: > # man curses | grep is_keypad > is_keypad curs_opaque(3X)* on FreeBSD 11: > # man curses | grep is_keypad > is_keypad curs_opaque(3X)* (the same) So it's in the man page, but not in the library Chances are all 13 "curs_opaque(3X)" functions are missing.
I suspect NCURSES_OPAQUE needs to be defined somewhere, and defined as "0". On DragonFly it is handled here: lib/libncurses/include/curses.head
(In reply to John Marino from comment #3) These are in the header files. I wonder if they should be defined as 1? Because the linker is complaining about a missing symbol, it suggests the accessors are functions and not macros. What's the side effect if we make the library NCURSES_OPAQUE? It sounds like it doesn't change the ABI but will potentially break certain applications that accesses the internals directly? Adding rafan@ just in case.
I thought they were opaque, which is why the symbols were missing. Setting it to "0" would make them not opaque. However, bapt seemed to say that this was set to "0" already.
Is there anything to report here? I'm getting pkg-fallout messages a couple of times a week about this, it's sort of annoying. I don't want to mask the port because it will mask the regression but at some port I probably will.
Can somebody *please* tell me if what I have reported is considered a bug and therefore there is intention to fix it? If there is no intention to fix this then we should close the PR and I will make adjustments. If there is an intention to fix curses in base, can we start fixing it?
A commit references this bug: Author: marino Date: Tue May 26 14:12:40 UTC 2015 New revision: 387478 URL: https://svnweb.freebsd.org/changeset/ports/387478 Log: devel/adacurses: work around FreeBSD 11 ncurses regression The upgrade of ncurses on the -CURRENT version of FreeBSD resulted in an regression (see PR) which results in multiple pkg-fallout mails to me weekly. Since the PR isn't moving despite periodic pinging, I am forcing the ports version of ncurses to be used with FreeBSD 11 rather than the base like FreeBSD 10 and earlier, and DragonFly. While here, tweak a makefile install target that was emitting a non-fatal error. PR: 199109 Changes: head/devel/adacurses/Makefile
given that FreeBSD 11 is locked down, this is clearly a WONTFIX scenario so I'm closing the PR. In any case, this is the new normal.