Re: pkg/51689: devel/ncurses DragonFly libncurses.la has wrong libdir

[David Shao <davshao%gmail.com@localhost>]

The following reply was made to PR pkg/51689; it has been noted by GNATS.

From: David Shao <davshao%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: pkg/51689: devel/ncurses DragonFly libncurses.la has wrong libdir
Date: Sun, 4 Dec 2016 19:50:35 -0800

 Sorry I did not make this clear.  There are multiple issues.
 
 I cannot verify at the moment because I am rebuilding a system after
 having to replace a motherboard, but I believe devel/ncurses has
 problems even building on recent FreeBSD that changed the name of its
 std c++ library.  That explains the lines in the patches:
 
 + case $cf_cv_system_name in
 ++(freebsd*)
 ++    cf_stdcpp_libname=c++
 ++    ;;
 
 So why hasn't this been noticed by anyone else?  I believe for almost
 anyone else, FreeBSD's base (n)curses implementation works fine, so
 usually pkgsrc ncurses does not have to be built.  I ran into this
 problem immediately because I standardized on
 
 PREFER_PKGSRC = yes
 CURSES_DEFAULT=ncurses
 READLINE_DEFAULT=readline
 
 FreeBSD ports does not notice because I believe an essential
 distinction may be that pkgsrc is building the C++ bindings while
 ports is not.  From pkgsrc devel/ncurses/Makefile.common:
 
 CONFIGURE_ARGS+=    --with-cxx-binding
 
 The big problem with devel/ncurses is indeed DragonFly, but I believe
 it may apply to any system that has privatized its base (n)curses even
 to the point where header files are not in the usual /usr/include.  I
 believe there is some interaction in the build when C++ bindings are
 enabled and when the base system lacks any trace of (n)curses that
 causes problems setting DESTDIR.  The heart of the patch for DragonFly
 is
 
 ++    if test "$cf_dir" == "c++" ; then
 ++        echo '    cd ncurses && ${MAKE} ${TOP_MFLAGS} $@' >>Makefile
 ++    fi
 ++
 
 (ncurses seems to generate its own Makefile) which simply adds another
 pass into ncurses to make whatever newly generated file may exist,
 somehow avoiding the bad DESTDIR problem.  My own testing with modular
 NetBSD and FreeBSD seems to indicate no problems with this extra pass.
 
 I made this PR so the information in it would be available for easy query.