[GRASS5] configuration/build failure on solaris 8, curses and get/putwc

GRASS GRASS developer
1

The subject line refers to the cause of the problem, not just my reaction to it. I believe the problem is nested includes from "curses" redefining getwc/putwc. This is on Solaris 8 (Sparc) with gcc 2.8. My results reported are from the current CVS build, but my results with pre4 were similar.

"configure" with the current release tree, and with pre4, fails with the following error:

checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for curses.h... no
configure: error: *** Unable to locate curses includes.

However, I think the problem surfaces higher up, where "configure" reports

checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for curses.h... no
checking for limits.h... yes

The log file segment for the initial curses.h check looks like this:

configure:2319: checking for curses.h
configure:2327: gcc -E conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/curses.h:23,
                  from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/include
/curses.h:5,
                  from configure:2323:
/usr/include/widec.h:38: warning: `getwc' redefined
/usr/include/iso/wchar_iso.h:337: warning: this is the location of the previous
definition
/usr/include/widec.h:39: warning: `putwc' redefined
/usr/include/iso/wchar_iso.h:340: warning: this is the location of the previous
definition
/usr/include/widec.h:40: warning: `getwchar' redefined
/usr/include/iso/wchar_iso.h:338: warning: this is the location of the previous
definition
/usr/include/widec.h:41: warning: `putwchar' redefined
/usr/include/iso/wchar_iso.h:341: warning: this is the location of the previous
definition
configure: failed program was:
#line 2322 "configure"
#include "confdefs.h"
#include <curses.h>
configure:2319: checking for limits.h

and the final segment of the log file looks like this:

configure:3629: gcc -o conftest -g -O2 -L/usr/openwin/lib conftest.c -lICE -lsocket -lnsl 1>&5
configure:3669: checking for curses.h
configure:3677: gcc -E conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/curses.h:23,
                  from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/include/curses.h:5,
                  from configure:3673:
/usr/include/widec.h:38: warning: `getwc' redefined
/usr/include/iso/wchar_iso.h:337: warning: this is the location of the previous definition
/usr/include/widec.h:39: warning: `putwc' redefined
/usr/include/iso/wchar_iso.h:340: warning: this is the location of the previous definition
/usr/include/widec.h:40: warning: `getwchar' redefined
/usr/include/iso/wchar_iso.h:338: warning: this is the location of the previous definition
/usr/include/widec.h:41: warning: `putwchar' redefined
/usr/include/iso/wchar_iso.h:341: warning: this is the location of the previous definition
configure: failed program was:
#line 3672 "configure"
#include "confdefs.h"
#include <curses.h>

----
Hal Mueller hal@mobilegeographics.com
Mobile Geographics LLC http://www.mobilegeographics.com/
Seattle, Washington (206) 297-9575
MapTap public test now underway! http://www.mobilegeographics.com/maptap/

2

Hal Mueller wrote:

The subject line refers to the cause of the problem, not just my
reaction to it. I believe the problem is nested includes from
"curses" redefining getwc/putwc. This is on Solaris 8 (Sparc) with
gcc 2.8. My results reported are from the current CVS build, but my
results with pre4 were similar.

"configure" with the current release tree, and with pre4, fails with
the following error:

checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for curses.h... no
configure: error: *** Unable to locate curses includes.

However, I think the problem surfaces higher up, where "configure" reports

checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for curses.h... no
checking for limits.h... yes

The log file segment for the initial curses.h check looks like this:

configure:2319: checking for curses.h
configure:2327: gcc -E conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/curses.h:23,
                  from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/include
/curses.h:5,
                  from configure:2323:
/usr/include/widec.h:38: warning: `getwc' redefined
/usr/include/iso/wchar_iso.h:337: warning: this is the location of the previous
definition
/usr/include/widec.h:39: warning: `putwc' redefined
/usr/include/iso/wchar_iso.h:340: warning: this is the location of the previous
definition
/usr/include/widec.h:40: warning: `getwchar' redefined
/usr/include/iso/wchar_iso.h:338: warning: this is the location of the previous
definition
/usr/include/widec.h:41: warning: `putwchar' redefined
/usr/include/iso/wchar_iso.h:341: warning: this is the location of the previous
definition
configure: failed program was:
#line 2322 "configure"
#include "confdefs.h"
#include <curses.h>
configure:2319: checking for limits.h

Two comments.

1. autoconf's AC_TRY_CPP macro (used by AC_CHECK_HEADERS) fails if the
preprocessor writes anything to stderr, even if they are only
warnings. You could try 'CPPFLAGS=-w ./configure ...'.

2. Ultimately the problem is with the development environment. Have
you tried (re)running gcc's "fixincludes" script? If that fails, my
only suggestion is to modify curses.h so that it can be included
without generating any warnings. I would assume that any configure
script will have the same problems.

--
Glynn Clements <glynn.clements@virgin.net>

3

Thanks for the help, everyone. Redefining CPPFLAGS to ignore warnings did the trick.

I don't know whether "fixincludes" was run; I am using a canned Solaris GCC package from sunfreeware.com, which I obtained sometime during the Clinton administration. It's gcc 2.8, woefully out of date I know.

Builds of both pre4 and the current CVS tree went fine, at least until I filled up my /opt partition. I've rearranged space and am rebuilding, but I don't see any reason things won't work. I'll post a "success" message for the dev tree when I get one, and will also be setting up to do a nightly CVS update/rebuild on the dev tree.

H