RE: [GRASS5] Solaris9 test of 5.4

GRASS GIS GRASS GIS developer
1

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@virgin.net>

Thanks for your detailed response Glynn.

- Bev

2

On Tue, 26 Oct 2004 11:58, Wallace, Beverly T wrote:

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?

I've just installed Grass 5.4pre1 on an almost clean Solaris 9 box with the
following steps - no changes to configure:

Download and install packages from sunfreeware (those marked with an * may not
have been necessary after all - other versions are already installed under /
usr/sfw):

bison
flex
freetype *
gcc
libiconv *
libpng *
make
mesa
tcl *
tk *
zlib *
jpeg *
readline
tar

With PATH=/usr/local/bin:/usr/bin:/usr/ccs/bin

download then configure; make; make install the following packages:
R
postgres
proj
fftw
unixODBC
gdal

Then from the grass directory:
mkdir build
cd build
../configure --with-includes="/usr/sfw/include /usr/local/pgsql/include" \
                 --with-libs="/usr/sfw/lib /usr/local/pgsql/lib"
make
make install

works fine.

It would be nice if grass was also a simple configure; make; make install.
If configure would look for postgress in /usr/local/pgsql and include /usr/
sfw/{include,lib} on solaris it would be good.

Regards
Gordon

--

Gordon Keith
Programmer/Data Analyst
Marine Acoustics
CSIRO Marine Research
http://www.marine.csiro.au

In theory there is no difference between theory and practice.
In practice there is.

3

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@virgin.net>

4

Gordon Keith wrote:

It would be nice if grass was also a simple configure; make; make install.
If configure would look for postgress in /usr/local/pgsql and include /usr/
sfw/{include,lib} on solaris it would be good.

The configure script used to autodetect directories; we took that
feature out because it tended to find things which broke the build,
making it impossible for some users to build GRASS.

This was a significant problem on systems which have GNU versions of
"base" components (e.g. libc, the C compiler) but where the GNU
versions aren't the "official" versions (i.e. everything except
Linux).

Eliminating the need to supply configure switches was considered less
important than making it possible to build GRASS on a wide variety of
systems.

--
Glynn Clements <glynn@gclements.plus.com>

5

On Tue, 26 Oct 2004 17:44, Glynn Clements wrote:

Gordon Keith wrote:
> It would be nice if grass was also a simple configure; make; make
> install. If configure would look for postgress in /usr/local/pgsql and
> include /usr/ sfw/{include,lib} on solaris it would be good.

The configure script used to autodetect directories; we took that
feature out because it tended to find things which broke the build,
making it impossible for some users to build GRASS.

OK, sounds reasonable.

I still think ./configure; make; make install should work inmost cases, at
least for a stable release (5.4).

Currently there seems to be two problems:
1) you need to create and use a separate build directory
2) postgres puts it's bits in /usr/local/pgsql instead of /usr/local

I know nothing about how to fix 1 but would it be possible to create a default
build directory and use it unless a switch is provided (eg --build-dir=)

With 2 it would be good if either the default build was --without-postgres or
configure looked for postgres files under /usr/local/pgsql. I suspect the
former may be cleaner. If you have to specify postgress include and lib
switches then having to provide --with-postgress makes sense.

Just my $0.02 as someone who only installs grass occassionaly and would really
like to be able to just install it without having to figure out all the
configure switches first.

Regards
Gordon
--

Gordon Keith
Programmer/Data Analyst
Marine Acoustics
CSIRO Marine Research
http://www.marine.csiro.au

The world and everything in it that people desire is passing away;
but he who does the will of God lives for ever.
  -- 1 John 2:17

6

Gordon Keith wrote:

> > It would be nice if grass was also a simple configure; make; make
> > install. If configure would look for postgress in /usr/local/pgsql and
> > include /usr/ sfw/{include,lib} on solaris it would be good.
>
> The configure script used to autodetect directories; we took that
> feature out because it tended to find things which broke the build,
> making it impossible for some users to build GRASS.

OK, sounds reasonable.

I still think ./configure; make; make install should work inmost cases, at
least for a stable release (5.4).

Currently there seems to be two problems:
1) you need to create and use a separate build directory

That's quite common for large projects; e.g. both gcc and glibc now
require this (or, at least, state that building within the source tree
is "unsupported").

The advantages include:

1. Eliminating the need for a recursive "make distclean" mechanism
(you can just "rm -rf ..." the build directory).

2. Eliminating the need to run "make distclean" before "cvs update".

3. Being able to keep multiple builds on the same system, e.g. keeping
both debug and optimised (or with and without postgres) builds lying
around.

4. Being able to build for multiple systems from a single source tree
(which can be shared via NFS or similar).

5. You don't need write permission on the source tree in order to
build it (which is useful if it's a read-only NFS export, or you want
to build someone else's tree on a multi-user system).

2) postgres puts it's bits in /usr/local/pgsql instead of /usr/local

More precisely, the headers normally go into a separate subdirectory
(not necessarily "pgsql"; IIRC, Cygwin uses "postgres"), but the
headers aren't designed to be used that way.

For comparison, X11 headers go into a subdirectory, but the
subdirectory forms part of the name by which the headers include each
other, e.g. "#include <X11/Xlib.h>". Same with OpenGL, GTK+ etc.

Also, headers are often put into a subdirectory to *prevent* them from
being picked up automatically (e.g. GTK+ 2.x "hides" its headers in a
subdirectory so that GTK+ 1.x programs don't use them accidentally).

I know nothing about how to fix 1 but would it be possible to create a default
build directory and use it unless a switch is provided (eg --build-dir=)

With 2 it would be good if either the default build was --without-postgres or
configure looked for postgres files under /usr/local/pgsql.

If --without-postgres was the default, we'd be forever dealing with
queries of the form "the postgres-related modules don't work".

Forcing users to supply switches was a deliberate decision, on the
grounds that users seem to find it hard to overlook the fact that they
had to discover and then supply a switch whereas they found it very
easy to overlook a "WARNING: PostgreSQL support disabled" message.

BTW, /usr/local/pgsql isn't the right place in most cases. While GDAL,
PROJ and (to a lesser extent) FFTW are fairly obscure, and may have to
be installed from source or a third party package, most Linux vendors
provide an official PostgreSQL package (RPM/.deb/etc) which installs
under /usr.

I suspect the
former may be cleaner. If you have to specify postgress include and lib
switches then having to provide --with-postgress makes sense.

Just my $0.02 as someone who only installs grass occassionaly and would really
like to be able to just install it without having to figure out all the
configure switches first.

Given that most users will probably have to locate and install (and
quite possibly compile) at least one of PROJ, GDAL and/or FFTW (the
rest are often already installed), expecting them to supply a couple
of switches isn't considered a big deal. It also has the advantage of
coercing them into reading the "configure --help" text.

In short, the need to supply a few switches in typical cases has as
much to do with psychology as with technical issues.

Also, it helps acclimate them to the fact that, once GRASS has finally
been compiled and installed, typing "grass" doesn't present them with
an intuitive GUI program which can be used productively without
reading a word of documentation. It's not that kind of package.

--
Glynn Clements <glynn@gclements.plus.com>