|
From: | Charles Wilson |
Subject: | Re: [PATCH] cygwin sharedlib build fixes, terminfo |
Date: | Sun, 03 Aug 2003 17:01:40 -0400 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 |
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 xlCSo, 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?In any event, you don't need the --tag stuff; I'll send a delta-patch (e.g. changes beyond the ones I posted earlier) to eliminate it.
-- Chuck
[Prev in Thread] | Current Thread | [Next in Thread] |