[GRASS5] grass-5.0.0 on SGI IRIX 6.5

Andreas_C_Lange · December 9, 2002, 4:40pm

Hi,

today i tried to recompile the grass source from september (5.0.0) on
IRIX 6.5.17m.
I experience two problems:
- src/display/devices/PNGdriver/Gmakefile needs a $(MATHLIB) added to
the LIBES line:
LIBES = $(DRIVERLIB) $(GISLIB) $(MATHLIB)
I can not build PNGdriver with latest GD lib, as i am unable to compile
GD myself on IRIX (the freeware version from SGI is 1.8.4).

- nviz does not compile:
(snippet from the output)
gcc -I/opt/grass/grass-5.0.0/src/include -g -O2
-I/usr/freeware/include -I/usr/freeware/include -I/usr/freeware/include
-I/opt/grass/grass-5.0.0/src/libes/ogsf -D_NO_PROTO -D__STDC__ -c
togl.c -o OBJ.mips-sgi-irix6.5/togl.o
<command line>: warning: "__STDC__" redefined
<builtin>: warning: this is the location of the previous definition
togl.c:163: parse error before "Sorry"
togl.c:163: parse error before "will"
togl.c: In function `SetupOverlay':
togl.c:1261: `TkWindow' undeclared (first use in this function)
togl.c:1261: (Each undeclared identifier is reported only once
togl.c:1261: for each function it appears in.)
togl.c:1261: `winPtr' undeclared (first use in this function)
togl.c:1261: parse error before ')' token
togl.c: In function `Togl_MakeWindowExist':
togl.c:1382: `TkWindow' undeclared (first use in this function)
togl.c:1382: `winPtr' undeclared (first use in this function)
togl.c:1382: parse error before ')' token
togl.c:1383: `winPtr2' undeclared (first use in this function)
togl.c: In function `ToglCmdDeletedProc':
togl.c:1899: `TkWindow' undeclared (first use in this function)
togl.c:1899: `winPtr' undeclared (first use in this function)
togl.c:1899: parse error before ')' token

IMHO somehow the including of the header tkInt.h is broken, i have
installed Tcl 8.0.4 and Tk 8.0.4 (both from SGI IRIX freeware, there is
no newer version).

my configure line:
./configure --prefix=/opt --with-libs=/usr/freeware/lib32 \
--with-includes=/usr/freeware/include --with-odbc=no --with-motif=yes \
--with-tcltk-libs=/usr/freeware/lib32 \
--with-tcltk-includes=/usr/freeware/include

If i get nviz to compile, i'll prepare a binary package and upload.

Andreas
--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850

Paul_Kelly · December 9, 2002, 8:14pm

Hello

On Mon, 9 Dec 2002, Andreas Lange wrote:

Hi,

today i tried to recompile the grass source from september (5.0.0) on
IRIX 6.5.17m.
I experience two problems:
- src/display/devices/PNGdriver/Gmakefile needs a $(MATHLIB) added to
the LIBES line:
LIBES = $(DRIVERLIB) $(GISLIB) $(MATHLIB)
I can not build PNGdriver with latest GD lib, as i am unable to compile
GD myself on IRIX (the freeware version from SGI is 1.8.4).

- nviz does not compile:
(snippet from the output)

IMHO somehow the including of the header tkInt.h is broken, i have
installed Tcl 8.0.4 and Tk 8.0.4 (both from SGI IRIX freeware, there is
no newer version).

my configure line:
./configure --prefix=/opt --with-libs=/usr/freeware/lib32 \
--with-includes=/usr/freeware/include --with-odbc=no --with-motif=yes \
--with-tcltk-libs=/usr/freeware/lib32 \
--with-tcltk-includes=/usr/freeware/include

(I have compiled GRASS on IRIX several times)
Sorry I can't help with those problems as I didn't have any of them. I'm
also using GD 1.8.4 (as far as I can remember I couldn't get version 2
compiled either) but Tcl/Tk 8.2.3 (it is very simple to compile from
source).

If i get nviz to compile, i'll prepare a binary package and upload.

Is there a problem with the current IRIX binary package? I experimented
with compiling optimised for mips3 and n32 but found that nviz wouldn't
run when compiled like this on IRIX 6.2 (ran OK on 6.4); there was a bus
error or segmentation fault (sorry can't remember which any more). I had a
quick look with gdb but it was all over my head and seeing the mips2 / o32
binary ran fine I just left it at that.

So there didn't seem to be anything for me to update in the current
binary. It was compiled from the release branch only a matter of days
before 5.0.0 was tagged and released so although it is labelled 5.0.0pre5
I think there should be very little difference.

The only problem is the Escape and Return keys not working when run from
an IRIX winterm. I at least should have proposed a change to the README on
the ftp server to mention this; sorry. The partial fix for this has now been
merged into the release branch, but still it means the arrow keys don't work
now. I was waiting until we got this sorted out before compiling another binary
package.

Also the current binary package includes SG3d, sg4d and all g3d stuff.
Markus agreed this was a good idea and I know I couldn't do without SG3d
for my current research, but maybe it isn't absolutely necessary. I
suppose overall it would be a good idea to compile everything with the
latest versions of the pre-compiled SGI freeware packages as that is what a
lot of people may be using (not me though).

Paul Kelly

neteler · December 9, 2002, 9:15pm

On Mon, Dec 09, 2002 at 08:14:19PM +0000, Paul Kelly wrote:
[...]

The only problem is the Escape and Return keys not working when run from
an IRIX winterm. I at least should have proposed a change to the README on
the ftp server to mention this; sorry. The partial fix for this has now been
merged into the release branch, but still it means the arrow keys don't work
now. I was waiting until we got this sorted out before compiling another binary
package.

The arrow keys are also broken for me: Linux, HEAD, at least in
the startup script. Broken in xterm as well as KDE-term. This is a bit
odd, because it was working and I like the keys. I can report that
for Suse 7.3 and Redhat 7.1 (with updates).
Does it have to do with the recent TERMLIB changes?

[...]

Markus

Glynn_Clements · December 9, 2002, 9:50pm

Andreas Lange wrote:

today i tried to recompile the grass source from september (5.0.0) on
IRIX 6.5.17m.
I experience two problems:
- src/display/devices/PNGdriver/Gmakefile needs a $(MATHLIB) added to
the LIBES line:
LIBES = $(DRIVERLIB) $(GISLIB) $(MATHLIB)

Actually, $(MATHLIB) needs to be (conditionally) added to the
definition of GDLIB. The PNG driver doesn't use any math functions
directly; it's GD which uses them.

This change has recently been made to the CVS head version of
configure[.in].

- nviz does not compile:
(snippet from the output)
gcc -I/opt/grass/grass-5.0.0/src/include -g -O2
-I/usr/freeware/include -I/usr/freeware/include -I/usr/freeware/include
-I/opt/grass/grass-5.0.0/src/libes/ogsf -D_NO_PROTO -D__STDC__ -c
togl.c -o OBJ.mips-sgi-irix6.5/togl.o
<command line>: warning: "__STDC__" redefined
<builtin>: warning: this is the location of the previous definition
togl.c:163: parse error before "Sorry"
togl.c:163: parse error before "will"

This is due to use of an unsupported Tcl/Tk version; however, someone
omitted the "#" from "#error", so the error message is unclear.

Try adding:

#elif TK_MAJOR_VERSION==8 && TK_MINOR_VERSION==0 && TK_RELEASE_SERIAL==4
# include "tkInt8.0.2.h"

at the top of togl.c.

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

Andreas_C_Lange · December 9, 2002, 10:14pm

Hi Paul,

Paul Kelly wrote:

(I have compiled GRASS on IRIX several times)
Sorry I can't help with those problems as I didn't have any of them. I'm
also using GD 1.8.4 (as far as I can remember I couldn't get version 2
compiled either) but Tcl/Tk 8.2.3 (it is very simple to compile from
source).

I need the 24bit PNGdriver, maybe others too.

>
> If i get nviz to compile, i'll prepare a binary package and upload.

Is there a problem with the current IRIX binary package? I experimented
with compiling optimised for mips3 and n32 but found that nviz wouldn't
run when compiled like this on IRIX 6.2 (ran OK on 6.4); there was a bus
error or segmentation fault (sorry can't remember which any more). I had a
quick look with gdb but it was all over my head and seeing the mips2 / o32
binary ran fine I just left it at that.

Thanks for your quick response. There is nothing wrong with your binary
package, but i want to compile myself because i want to do own c
programming. And i think it would be a good idea to update the binary
package to 5.0.0.
The irix freeware does no longer support IRIX 6.2, so i do not worry
about that.

So there didn't seem to be anything for me to update in the current
binary. It was compiled from the release branch only a matter of days
before 5.0.0 was tagged and released so although it is labelled 5.0.0pre5
I think there should be very little difference.

The only problem is the Escape and Return keys not working when run from
an IRIX winterm. I at least should have proposed a change to the README on
the ftp server to mention this; sorry. The partial fix for this has now been
merged into the release branch, but still it means the arrow keys don't work
now. I was waiting until we got this sorted out before compiling another binary
package.

Also the current binary package includes SG3d, sg4d and all g3d stuff.
Markus agreed this was a good idea and I know I couldn't do without SG3d
for my current research, but maybe it isn't absolutely necessary. I
suppose overall it would be a good idea to compile everything with the
latest versions of the pre-compiled SGI freeware packages as that is what a
lot of people may be using (not me though).

I think it is very good to include those stuff, but i think it would be
important to have a list and some hints on how to compile the extra SG3d
etc. programs. Compilation should be as generic as possible.
I personally prefer to have my development machine only with the
precompiled SGI freeware packages to get the dependencies correct. If
nviz does not compile with stock tcl/tk 8.0.4 i consider this broken.
Any ideas how to fix togl.c?

Andreas

--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850

neteler · December 9, 2002, 10:26pm

Hi Andreas,

On Mon, Dec 09, 2002 at 11:14:10PM +0100, Andreas Lange wrote:
[...]

I personally prefer to have my development machine only with the
precompiled SGI freeware packages to get the dependencies correct. If
nviz does not compile with stock tcl/tk 8.0.4 i consider this broken.
Any ideas how to fix togl.c?

Yes:

you have to get the tcl/tk 8.0.4 source code and extract the
tkInt8.0.4.h
file. Then edit the togl.c and add an 'if' condition there for
this version (you will easily understand how to do that):
Somethink like this:

#elif TK_MAJOR_VERSION==8 && TK_MINOR_VERSION==0 && TK_RELEASE_SERIAL==4
# include "tkInt8.0.4.h"

If it works, please update the CVS (or send it to me).

Good luck,

Markus

Glynn_Clements · December 10, 2002, 1:55am

Markus Neteler wrote:

> The only problem is the Escape and Return keys not working when run from
> an IRIX winterm. I at least should have proposed a change to the README on
> the ftp server to mention this; sorry. The partial fix for this has now been
> merged into the release branch, but still it means the arrow keys don't work
> now. I was waiting until we got this sorted out before compiling another binary
> package.

The arrow keys are also broken for me: Linux, HEAD, at least in
the startup script. Broken in xterm as well as KDE-term. This is a bit
odd, because it was working and I like the keys. I can report that
for Suse 7.3 and Redhat 7.1 (with updates).
Does it have to do with the recent TERMLIB changes?

Possibly. There are two different databases of terminal descriptions:
termcap (typically /etc/termcap) and terminfo (typically
/usr/lib/terminfo/* or /usr/share/terminfo/*).

The functions which obtain this data (e.g. tgetent) may obtain it from
either database. Furthermore, there are often multiple implementations
of these functions (on my RedHat 6.2 system, tgetent is provided by
all three of libtermcap, libtinfo and libncurses).

Basically, you need to ensure that both databases accurately describe
the behaviour of the terminal when in "application keypad" mode. (If
you look at xterm's middle-button menu both normally and when using a
vask-based input form; in the latter situation, both the "Enable
Application Cursor Keys" and "Enable Application Keypad" options
should have tick (check) marks).

Note that the choice of entry is determined by the value of $TERM,
which may not actually be "xterm". Because xterm has so many possible
variations, it is necessary to have lots of different termcap entries;
e.g. I have:

  xterm xterm-16color xterm-24 xterm-65 xterm-8bit xterm-bold
  xterm-boldso xterm-color xterm-ic xterm-mono xterm-new
  xterm-nic xterm-nrc xterm-old xterm-r5 xterm-r6 xterm-redhat
  xterm-rep xterm-sun xterm-vi xterm-vt220 xterm-xfree86
  xterm-xmc xterm1 xtermc xtermm xterms xterms-sun

You need to pick the one which matches xterm's actual behaviour.

You can examine the contents of the termcap file directly; you can
decode the binary terminfo file for a specific terminal with
"infocmp". Typical entries for xterm are:

  key t'info t'cap sequence
  up kcuu1 ku \EOA
  down kcud1 kd \EOB
  right kcuf1 kr \EOC
  left kcub1 kl \EOD
  home khome kh \EOH
  end kend @7 \EOF

When not in application keypad mode, the arrow keys generate the
cursor motion codes (the ones which an application sends to the
terminal to move the cursor).

Also, if the terminal requires a specific sequence to enable
application mode, that must be specified directly; for xterm, it is:

smkx ks \E[?1h\E=

More information on terminal capabilities can be obtained from the
termcap, terminfo and ncurses manpages. More information on xterm can
be obtained from the xterm manpage.

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

neteler · December 10, 2002, 10:00am

On Tue, Dec 10, 2002 at 01:55:35AM +0000, Glynn Clements wrote:

Markus Neteler wrote:

> > The only problem is the Escape and Return keys not working when run from
> > an IRIX winterm. I at least should have proposed a change to the README on
> > the ftp server to mention this; sorry. The partial fix for this has now been
> > merged into the release branch, but still it means the arrow keys don't work
> > now. I was waiting until we got this sorted out before compiling another binary
> > package.
>
> The arrow keys are also broken for me: Linux, HEAD, at least in
> the startup script. Broken in xterm as well as KDE-term. This is a bit
> odd, because it was working and I like the keys. I can report that
> for Suse 7.3 and Redhat 7.1 (with updates).
> Does it have to do with the recent TERMLIB changes?

Possibly. There are two different databases of terminal descriptions:
termcap (typically /etc/termcap) and terminfo (typically
/usr/lib/terminfo/* or /usr/share/terminfo/*).

The functions which obtain this data (e.g. tgetent) may obtain it from
either database. Furthermore, there are often multiple implementations
of these functions (on my RedHat 6.2 system, tgetent is provided by
all three of libtermcap, libtinfo and libncurses).

[...xterm explanations...]

I must admit that I am no termcap expert.
From a user's perspective (which is not necessarily a developer's
perspective) I "just" see that previous functionionality is gone.
IMHO GRASS should support cursor keys without changing the
system's settings (support out of the box).

In summary, what could be done to get the cursor key support
back? Maybe I am missing something.

Markus

Glynn_Clements · December 10, 2002, 11:44pm

Markus Neteler wrote:

[...xterm explanations...]

I must admit that I am no termcap expert.
>From a user's perspective (which is not necessarily a developer's
perspective) I "just" see that previous functionionality is gone.
IMHO GRASS should support cursor keys without changing the
system's settings (support out of the box).

Garbage in, garbage out. If the system lies about which codes are
needed to enable the cursor keys and/or which codes the cursor keys
generate, curses won't be able to recognise that a cursor key was
pressed.

However, it isn't certain that this is a termcap/terminfo issue. Did
the configure script detect keypad()? The message looks like:

checking for keypad in -lncurses... yes

Or check whether HAVE_KEYPAD is defined in config.h, or whether
running "nm -D" on a vask-using program shows a dependency upon
"keypad".

Which library is actually being used? (run "ldd" on any vask-using
program, e.g. etc/set_data). What is $TERM? Are either of TERMCAP or
TERMINFO set in the environment? Do you have a terminfo entry for
$TERM?

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

neteler · December 11, 2002, 9:39am

On Tue, Dec 10, 2002 at 11:44:35PM +0000, Glynn Clements wrote:

Markus Neteler wrote:

> [...xterm explanations...]
>
> I must admit that I am no termcap expert.
> >From a user's perspective (which is not necessarily a developer's
> perspective) I "just" see that previous functionionality is gone.
> IMHO GRASS should support cursor keys without changing the
> system's settings (support out of the box).

Garbage in, garbage out. If the system lies about which codes are
needed to enable the cursor keys and/or which codes the cursor keys
generate, curses won't be able to recognise that a cursor key was
pressed.

ok.

However, it isn't certain that this is a termcap/terminfo issue. Did
the configure script detect keypad()? The message looks like:

checking for keypad in -lncurses... yes

checking for keypad in -lncurses... yes

uname -a
Linux thuille 2.4.18-18.7.xsmp #1 SMP Wed Nov 13 19:01:42 EST 2002 i686 unknown

Or check whether HAVE_KEYPAD is defined in config.h,

cat src/include/config.h | grep HAVE_KEYPAD
#define HAVE_KEYPAD 1

or whether
running "nm -D" on a vask-using program shows a dependency upon
"keypad".

nm -D dist.i686-pc-linux-gnu/etc/set_data | grep keypad
-> nothing

nm -D dist.i686-pc-linux-gnu/etc/bin/inter/v.digit | grep keypad
-> nothing

Which library is actually being used? (run "ldd" on any vask-using
program, e.g. etc/set_data).

ldd dist.i686-pc-linux-gnu/etc/set_data
        libncurses.so.5 => /usr/lib/libncurses.so.5 (0x40017000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0x4006f000)
        libm.so.6 => /lib/libm.so.6 (0x40073000)
        libz.so.1 => /usr/lib/libz.so.1 (0x40095000)
        libc.so.6 => /lib/libc.so.6 (0x400a3000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

What is $TERM?

echo $TERM
xterm

Are either of TERMCAP or TERMINFO set in the environment?

set | grep TERM
COLORTERM=
TERM=xterm

printenv | grep TERM
COLORTERM=
TERM=xterm

Do you have a terminfo entry for $TERM?

locate terminfo | grep 'xterm$'
/usr/share/terminfo/a/aixterm
/usr/share/terminfo/c/color_xterm
/usr/share/terminfo/f/fixterm
/usr/share/terminfo/j/jaixterm
/usr/share/terminfo/x/xterm

To be sure I have recompiled set_data:

gcc -I/hardmnt/thuille1/ssi/cvsgrass_exp/src/include -O3 -mcpu=pentiumpro -Wall -DD_LOCATION_NAME=\"\" -DD_GISDBASE=\"\" -DVERSION_NUMBER=\"'5.0.1-cvs'\" -DVERSION_UPDATE_PKG=\"''\" -c set_data.c -o OBJ.i686-pc-linux-gnu/set_data.o
set_data.c: In function `list_mapsets':
set_data.c:296: warning: suggest parentheses around assignment used as truth
valueset_data.c: At top level:
/hardmnt/thuille1/ssi/cvsgrass_exp/src/include/gis.h:35: warning: `GRASS_copyright' defined but not used
gcc -L/hardmnt/thuille1/ssi/cvsgrass_exp/src/libes/LIB.i686-pc-linux-gnu -o /amd/ssi0/ssi/neteler/cvsgrass_exp/dist.i686-pc-linux-gnu/etc/set_data OBJ.i686-pc-linux-gnu/set_data.o OBJ.i686-pc-linux-gnu/mke_mapset.o OBJ.i686-pc-linux-gnu/mke_loc.o OBJ.i686-pc-linux-gnu/chk_dbase.o OBJ.i686-pc-linux-gnu/other.o -lgedit -lgis -lvask -lncurses -lbsd-compat -lm -lz

nm -D dist.i686-pc-linux-gnu/etc/set_data | grep keypad
-> again nothing

grep ncurses src/CMD/head/head.i686-pc-linux-gnu
CURSES = -lncurses $(COMPATLIB)

locate libncurses
/usr/lib/libncurses.so.5
/usr/lib/libncurses.so.5.2
/usr/lib/libncurses.a
/usr/lib/libncurses.so
/usr/lib/libncurses.so.4
/usr/lib/libncurses.so.4.0

ls -la /usr/lib/libncurses.so
lrwxrwxrwx 1 root root 15 Aug 1 2001 /usr/lib/libncurses.so -> libncurses.so.5

nm -D /usr/lib/libncurses.so | grep keypad
00028b70 T _nc_keypad
00028920 T keypad

Layman's summary:
It seems that the symbol is present, detected, but not used in GRASS although
defined in config.h.

Markus