Bug 205155 - audio/ncmpcpp: ./configure fails after devel/ncurses 6.0 update
Summary: audio/ncmpcpp: ./configure fails after devel/ncurses 6.0 update
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Baptiste Daroussin
Keywords: patch, regression
Depends on:
Reported: 2015-12-09 10:17 UTC by yamagi
Modified: 2016-01-19 15:08 UTC (History)
3 users (show)

See Also:
koobs: maintainer-feedback? (yamagi)


Note You need to log in before you can comment on or make changes to this bug.
Description yamagi 2015-12-09 10:17:01 UTC
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)'
                                     ^               ~~~~~~
/usr/local/include/ncurses/unctrl.h:60:61: error: expected ';' after top level declarator
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 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 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 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

  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

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 2015-12-09 12:12:47 UTC
Comment 9 Christoph Moench-Tegeder freebsd_committer 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.