[GRASS5] Solaris9 test of 5.4

[Wallace, Beverly T]

> 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?

> > 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.

> 
> > 3) In r3.showdspf.openGL, new_init_graphics.c needs config.h and the
> > same GLwMDrawA.h includes as main_ogl.c.
> 
> Ok.
> 
> -- 
> Glynn Clements <glynn.clements at virgin.net>
> 

Thanks for your detailed response Glynn.

- Bev