Charles Wilson wrote:
a Makefile like that. Why is c++ "preferred" over g++....
So, that leaves two questions:
#1) why is ncurses configure determining that CXX should be 'c++' when
libtool's build procedure auto-found 'g++'?
I wonder if this stanza in ncurses configure.in is somehow the culprit:
if test "$CXX" = "g++" ; then
AC_PATH_PROG(CXX,g++)
fi
if test "$CXX" = "g++" ; then
AC_MSG_WARN(ignoring hardcoded g++)
cf_with_cxx=no; CXX=""; GXX="";
fi
Nope. The reason seems to be because of the different autoconf versions
used by ncurses (20020210-t.e.d.) and libtool-1.5 (2.57). In the
former, AC_PROG_CXX searches in this order:
for ac_prog in $CCC c++ g++ gcc CC cxx cc++ cl
but in the latter, AC_PROG_CXX searches in this order:
for ac_prog in $CCC g++ c++ gpp aCC CC cxx cc++ cl FCC KCC RCC xlC_r xlC
So, if you have both g++ and c++ (which I do; the default cygwin
installation installs a c++ -> g++ symlink in /usr/bin), you end up with
a libtool-1.5 that "knows" CXX should be g++, but ncurses thinks that
CXX should be c++.
This messes up libtools tag-inference code.
Solutions?
1) ncurses update to ac-2.57 (maybe get some of the more useful,
non-architectural T.E.D. modifications into ac-2.58?)
2) ac-20020210-T.E.D. changes AC_PROG_CXX search order to match ac-2.57?
3) builders on "problematic" platforms just 'export CXX=g++' before
configure?
(*) Unfortunately, this doesn't work either. The configury magic sees
the $CXX value, does a path lookup and puts the entire path into the
Makefile. Unfortunately, /usr/local/bin/g++ != g++.
others?