Bug 205155

Summary: audio/ncmpcpp: ./configure fails after devel/ncurses 6.0 update
Product: Ports & Packages Reporter: yamagi
Component: Individual Port(s)Assignee: Baptiste Daroussin <bapt>
Status: Closed FIXED    
Severity: Affects Only Me CC: bapt, cmt, yamagi
Priority: --- Keywords: patch, regression
Version: LatestFlags: koobs: maintainer-feedback? (yamagi)
Hardware: Any   
OS: Any   

Description yamagi 2015-12-09 10:17:01 UTC
Hello,
the update of devel/ncurses broke the configure script of audio/ncmpcpp. At this point I'm not sure if it's a general problem with devel/ncurses usage in C++ based programs or if audio/ncmpcpp has just a broken configure script / automake setup. The error is:

checking for ncursesw6-config... /usr/local/bin/ncursesw6-config
checking for initscr in -lncursesw... yes
checking for initscr in -lncursesw... yes
checking curses.h usability... no
checking curses.h presence... yes
configure: WARNING: curses.h: present but cannot be compiled
configure: WARNING: curses.h:     check for missing prerequisite headers?
configure: WARNING: curses.h: see the Autoconf documentation
configure: WARNING: curses.h:     section "Present But Cannot Be Compiled"
configure: WARNING: curses.h: proceeding with the compiler's result
checking for curses.h... no
configure: error: missing curses.h header

Interestingly the test for initscr() succeeds, but the following test for curses.h usability fails. Of course the config.log has some more informations. The compilation of the initscr succeeds, even in C++0x mode:

configure:17211: checking for initscr in -lncursesw
configure:17236: c++ -o conftest -O2 -pipe -DLIBICONV_PLUG -fstack-protector -fno-strict-aliasing  -DLIBICONV_PLUG -std=c++0x -I/usr/local/include -DLIBICONV_PLUG -I/usr/local/include   -I/usr/local/include   -D_BSD_TYPES -D__BSD_VISIBLE -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -I/usr/local/include/ncurses/ncursesw -I/usr/local/include/ncurses  -lpthread -L/usr/local/lib -Wl,-rpath=/usr/local/lib -fstack-protector conftest.cpp -lncursesw   -lboost_filesystem -lboost_system -lboost_locale -lboost_program_options -lboost_regex -L/usr/local/lib -licuuc -licudata   -lboost_thread -L/usr/local/lib -lmpdclient   -lreadline -lpthread -L/usr/local/lib -rpath /usr/local/lib -lncursesw -ltinfow >&5
configure:17236: $? = 0
configure:17246: result: yes

The curses.h test fails with type missmatches:

configure:17260: checking curses.h usability
configure:17260: c++ -c -O2 -pipe -DLIBICONV_PLUG -fstack-protector -fno-strict-aliasing  -DLIBICONV_PLUG -std=c++0x -I/usr/local/include -DLIBICONV_PLUG -I/usr/local/include   -I/usr/local/include   -D_BSD_TYPES -D__BSD_VISIBLE -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -I/usr/local/include/ncurses/ncursesw -I/usr/local/include/ncurses conftest.cpp >&5
In file included from conftest.cpp:81:
In file included from /usr/include/curses.h:141:
/usr/local/include/ncurses/unctrl.h:60:38: error: cannot initialize a variable of type 'const char *' with an lvalue of type 'const char *(chtype)'
NCURSES_EXPORT(NCURSES_CONST char *) NCURSES_SP_NAME(unctrl) (SCREEN*, chtype);
                                     ^               ~~~~~~
/usr/local/include/ncurses/unctrl.h:60:61: error: expected ';' after top level declarator
NCURSES_EXPORT(NCURSES_CONST char *) NCURSES_SP_NAME(unctrl) (SCREEN*, chtype);
                                                            ^
2 errors generated.
configure:17260: $? = 1

For now I'll switch audio/ncmpcpp back to ncurses:base. Nevertheless it would be nice if we could clarify if I'm seeing a general problem or if it's a problem limited to 'my' configure script.
Comment 1 Baptiste Daroussin freebsd_committer freebsd_triage 2015-12-09 10:29:36 UTC
The bug is in the ncmcpp port which mixes headers from base for ncurses with headers from ports. have curses.h from ncurses 5.x (base and using other headers from ncurses from ports).
Comment 2 yamagi 2015-12-09 10:41:44 UTC
Thank you. :) Now I'll need to think of a way how to fix that in ncmpcpp.
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2015-12-09 10:43:31 UTC
Since I re-did the issue summary, how about we leave this Open until you do? :)
Comment 4 yamagi 2015-12-09 10:45:10 UTC
Okay, I've reopened it.
Comment 5 Baptiste Daroussin freebsd_committer freebsd_triage 2015-12-09 11:51:43 UTC
Actually the bug is more tricky than that.

ncurses from ports never installed curses.h so that port always used the one from base with other headers from ports in case the port was installed. It has worked by chance for a while. I suspect other ports might have the same issue.

I will modify ncurses to install curses.h to avoid such mistake. That should fix ncmcpp
Comment 6 commit-hook freebsd_committer freebsd_triage 2015-12-09 11:57:50 UTC
A commit references this bug:

Author: bapt
Date: Wed Dec  9 11:57:16 UTC 2015
New revision: 403376
URL: https://svnweb.freebsd.org/changeset/ports/403376

Log:
  Install curses.h

  the ncurses ports was specially configured for a while to not install the
  curses.h header, expecting ports to use ncurses.h. How ever lots of ports are
  still using curses.h instead of ncurses.h. Those ended up using curses.h from
  base and other headers from the port. It worked by chances until now.

  Modify this port to make sure curses.h is installed so the ports will use the
  proper set of headers instead of mixing potentially incompatible ones.

  While here modify ncurses*6-config to prevent it to expose -I arguments pointing
  to a non existing directory

  PR:		205155
  Reported by:	yamagi@yamagi.org

Changes:
  head/devel/ncurses/Makefile
  head/devel/ncurses/pkg-plist
Comment 7 Kubilay Kocak freebsd_committer freebsd_triage 2015-12-09 11:59:04 UTC
I presume merge quarterly is not needed?
Comment 8 Baptiste Daroussin freebsd_committer freebsd_triage 2015-12-09 12:12:47 UTC
nope
Comment 9 Christoph Moench-Tegeder freebsd_committer freebsd_triage 2015-12-09 12:32:03 UTC
I believe this also fixes bug #205041
Comment 10 yamagi 2015-12-09 12:39:13 UTC
And since using /usr/include/curses.h worked by chance I didn't realize that ncmpcpp was mixing up base and ports ncurses. My solution would have been hacking the configure script and change the only curses.h include in the code. Not nice but less invasive than fixing that broken, homegrown curses detection logic... Of course having a /usr/local/include/ncurses/curses.h is a much nicer solution and I guess that it'll help other peoples too. Thank you. :)

I guess we're done here. I'll submit an updates patch to bug #205071 (ncmpcpp update) soon.