Bug 199109 - Regression seen with ncurses on 11-current
Summary: Regression seen with ncurses on 11-current
Status: Closed Not Accepted
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs mailing list
Keywords: regression
Depends on:
Reported: 2015-04-02 08:00 UTC by John Marino
Modified: 2016-08-16 13:19 UTC (History)
4 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description John Marino freebsd_committer 2015-04-02 08:00:57 UTC
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:


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?
Comment 1 John Marino freebsd_committer 2015-04-02 08:01:34 UTC
Adding the two developers involved with last update to ncurses in base.
Comment 2 John Marino freebsd_committer 2015-04-02 11:48:43 UTC
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.
Comment 3 John Marino freebsd_committer 2015-04-02 11:57:16 UTC
I suspect NCURSES_OPAQUE needs to be defined somewhere, and defined as "0".

On DragonFly it is handled here:
Comment 4 Xin LI freebsd_committer 2015-04-03 17:05:32 UTC
(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.
Comment 5 John Marino freebsd_committer 2015-04-08 22:31:21 UTC
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.
Comment 6 John Marino freebsd_committer 2015-04-24 22:03:57 UTC
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.
Comment 7 John Marino freebsd_committer 2015-05-21 09:07:22 UTC
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?
Comment 8 commit-hook freebsd_committer 2015-05-26 14:13:04 UTC
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

  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

  PR:	199109

Comment 9 John Marino freebsd_committer 2016-08-16 13:19:19 UTC
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.