[GRASS5] Solaris9 test of 5.4

[Glynn Clements]

Wallace, Beverly T wrote:

> > > I tested the 5.4 release candidate with Solaris9 and gcc 3.3.
> > > 
> > > Configure ran OK.  I had a few problems with the compilation.
> > > 
> > > 1)  I needed to change -lncurses to -lcurses in vars.mk.
> > 
> > My guess is that your curses.h corresponds to the latter.
> > 
> > The configure script checks for -lncurses first, and only checks for
> > -lcurses if that fails. However, it assumes that the header is called
> > curses.h (as does the code which uses it), and that the header
> > corresponds to whichever library it finds.
> > 
> > The only robust solution to the curses issue is to provide configure
> > switches which allow the user to explicitly specify the compiler and
> > linker switches which are to be used by code which requires curses. 
> > Any autodetection mechanism will fail in some cases.
> > 
> 
> I modified the configure script to check for initscr32 instead of
> initscr.
> It gives me the result that I need:  -lncurses fails and -lcurses works.
> Will this solution work for other systems?

Not in general. I suspect that the name initscr32 is related to having
with a choice of 32- or 64-bit ABIs. It's unlikely to exist on
platforms which don't provide multiple ABIs.

BTW, the code (e.g. V_call()) actually uses initscr(); presumably your
curses.h defines initscr as a macro which evaluates to initscr32. 

Unfortunately, the stock autoconf tests (e.g. AC_CHECK_FUNCS,
AC_CHECK_LIB) can't handle macros, as they don't use any headers. If
this (initscr vs initscr32) was the only issue, we could get around it
using AC_TRY_LINK. However, the curses issues go much deeper than
that.

> > > 2) Some programs still failed with messages about 
> > "initscr32". I added
> > > $(CURSES) to the makefile of d.measure and it fixed it. Presumably
> > > that is what the makefiles for these programs need:
> > 
> > This is because libgrass_I requires libgrass_vask, and libgrass_vask
> > requires curses. Ideally, $(IMAGERYLIB) should include $(VASKLIB), and
> > $(VASKLIB) should include $(CURSES), rather than the dependency going
> > into individual Gmakefiles.
> > 
> > In any case, d.measure doesn't actually use libgrass_I; the presence
> > of $(IMAGERYLIB) in the Gmakefile is gratuitous (as is $(GMATHLIB)).
> > 
> > The problems with the others are probably due to curses.
> 
> Good idea.  I simply added $(CURSES) to both VASKLIB and IMAGERYLIB in
> mid.mk and that fixed all the errors.

I will commit a fix to do this generally (i.e. include all of the
dependencies in each of the *LIB variables in mid.mk).

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