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.
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).
Thank you. :) Now I'll need to think of a way how to fix that in ncmpcpp.
Since I re-did the issue summary, how about we leave this Open until you do? :)
Okay, I've reopened it.
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
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
I presume merge quarterly is not needed?
nope
I believe this also fixes bug #205041
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.