[GRASS5] compiling grass5.0beta7 on SGI IRIX

GRASS GRASS developer
1

Hi,

i post here a lengthy description of what i expirienced compiling GRASS
5.0beta7 on SGI IRIX 6.2 with egcs 2.91.66.

Most of the problems will be solved if the new GNU autoconf system is
set up so i will not send patches for those problems. I want to stress
that for the modules using 'non-standard' libraries (libtiff, libpng)
the include directives (-I, -L) should be specified in the global header
file and in the Gmakefile of the module.

I had until now no time to check if the modules are working, i report
only if the compiling succeeded.

I would be glad if someone could give me a hint on the other compiling
errors. I will inspect NVIZ 2.2 and the other errors later.

cu,

Andreas

--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de, A.C.Lange@GMX.net

Libraries:

With IRIX 6.5 the header files and libraries are included with the
distribution of the operating system. Under IRIX 6.2 the IDO is needed.

installed GNU libraries:

glib 1.2
io
iostream
jpeg
ltdl
ncurses
netpbm
png
readline
tcl8.0
tiff
tk8.0
z

installed GNU tools:
make
groff
autoconf
automake
m4
perl5
libtool

22/4/2000: updated following libraries:
fw_libz-1.1.3
fw_libpng-1.0.6
fw_netpbm-1march1994
because the header files for libpng and libz had been missing.
Remember: You must install all dev- and hdr- components of
the libraries!

hint: i "GNUified" my machine, that means i replaced /bin/cc with
a link to egcs, /bin/f77 with a link to g77, replaced SGI make with a
link to GNU make, replaced nroff with a link to GNU groff etc.
and added /usr/freeware/bin in front of my $PATH.
If you have a standard IRIX installation you will possibly get
some more errors due to the paths and Gmakefiles of GRASS.
I would not recommend to make the above changes, as they can
render your machine incompatible with IRIX tools and compiler and
break automatic installation with the IRIX inst tool.

The compiling process in detail:

src/mapdev/v.geom:
Unresolved text symbol "mallopt" .. libbasic.a(malloc.o).

patch to Gmakefile (add ifdef for IRIX)
and patch to src/libes/geom/basic/malloc.c (not required!)
The code in malloc.c (mallopt function) is not strictly required,
it uses a feature of IRIX for debugging memory problems with malloc,
which is only useable if you compile the library with the DEBUG flag,
which will cause heavy performance penalties.

src/raster/r.binfer
in function yylex: yylineno undeclared
-> this means that flex should be called in lex-compatible mode
via flex -l.
changed src/CMD/head/head: flex to flex -l
howto include this into ./configure?

src/raster/r.cost:
INFINITY undeclared in function main.
use the patch from Pierre de Mouveaux (grasslist mail from 25. April
2000)

src/raster/r.in.png:
png.h: no such file or directory
pnm.h
png.h: ...
needs libpng and header files for this library.

This is a total mess:
We should define a $(PNGINC) and $(PNGLIB) in the main header file
and with the autoconf-system.
The Gmakefile for r.in.png does not use the header and library paths,
only uses EXTRA_CFLAGS to include -I/usr/X11R6/include/
Please correct this to a platform independed system!

pnm.h is part of netpbm library (i have installed netpbm-1mar1994)
The problem was that i did indeed install netpbm, but without the
dev and hdr components.

next problem is the double include of <math.h> in r.in.png.c.
Alex Shevlakov should revise the #include directives in
r.in.png and r.out.png:
#ifndef _MYINCLUDE_H
#define _MYINCLUDE_H
/* header stuff follows here */
#endif /* _MYINCLUDE_H */

r.in.ppm compiles!

r.out.png does not compile, same as above.
after installing dev and hdr from netpbm-1mar1994 it compiles.

src.contrib/GMSL/SG3d:
warning: #ifdef argument starts with a digit ...
warnings for incompatible pointer types etc.
show.c in function show_what: 192: empty character constant
show.c:115: structure has no member named 'count'
I don't know which libpanel to use, can not compile 9.6.
libpanel.a/libpanel.so is in /usr/freeware/lib32, but without req.
header file

src.contrib/GMSL/g3d/src3d/raster/r3.mkdspf
unresolved text symbol "floor", "ceil", "log" etc.
that means IMHO that $(MATHLIB) is missing in Gmakefile!
But this $(MATHLIB) is needed at compiling of the libraries for
g3d, i was not able to spot where to put the $(MAHTLIB) directive
in a Gmakefile. ?

src.contrib/CERL/raster/r.water.fea/src/programs/channelfea
unresolved text symbol "log" -- 1st referenced by
..libgis.a(put_row.o).
..

src.contrib/PURDUE/d.linegraph
unresolved text symbol "log" -- 1st referenced by .. libgis.a(put_row.o)
..

NVIZ2.2
libraries are in /usr/freeware/lib32
headers are (mainly) in /usr/freeware/include
./configure works if you know the locations of libraries.
togl.c:65: initializer element for configSpecs[0].offset is not constant
..
same error as in grass.50beta6, i have no fix for this.

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 6147
max: 0

2

Hi Andreas,

many thanks for your useful comments!

On Thu, May 04, 2000 at 11:45:16PM +0200, Andreas Lange wrote:

Hi,

i post here a lengthy description of what i expirienced compiling GRASS
5.0beta7 on SGI IRIX 6.2 with egcs 2.91.66.

The compiling process in detail:

src/mapdev/v.geom:
Unresolved text symbol "mallopt" .. libbasic.a(malloc.o).

On SuSe 6.3 I found:
/usr/include/malloc.h:extern int mallopt __MALLOC_P ((int __param, int __val));

Here is seems to be defined. No idea for you, sorry.

patch to Gmakefile (add ifdef for IRIX)

Mhh, once we had such ifdefs in Gmakefile. But they caused
problems on several machines.

and patch to src/libes/geom/basic/malloc.c (not required!)
The code in malloc.c (mallopt function) is not strictly required,
it uses a feature of IRIX for debugging memory problems with malloc,
which is only useable if you compile the library with the DEBUG flag,
which will cause heavy performance penalties.

What do you suggest for me?

This is a total mess:
We should define a $(PNGINC) and $(PNGLIB) in the main header file
and with the autoconf-system.

I have added it. Currently hard-coded, this needs to be finished
in "configure".

The Gmakefile for r.in.png does not use the header and library paths,
only uses EXTRA_CFLAGS to include -I/usr/X11R6/include/
Please correct this to a platform independed system!

I added $(PNGLIB) to the CC line.

next problem is the double include of <math.h> in r.in.png.c.

Fixed.

Alex Shevlakov should revise the #include directives in
r.in.png and r.out.png:
#ifndef _MYINCLUDE_H
#define _MYINCLUDE_H
/* header stuff follows here */
#endif /* _MYINCLUDE_H */

Added.

r.out.png does not compile, same as above.

Fixed.

src.contrib/GMSL/g3d/src3d/raster/r3.mkdspf
unresolved text symbol "floor", "ceil", "log" etc.
that means IMHO that $(MATHLIB) is missing in Gmakefile!
But this $(MATHLIB) is needed at compiling of the libraries for
g3d, i was not able to spot where to put the $(MAHTLIB) directive
in a Gmakefile. ?

This is not possible in a lib. So I added in main.c:

#include <math.h>

Does this help for you?

src.contrib/CERL/raster/r.water.fea/src/programs/channelfea
unresolved text symbol "log" -- 1st referenced by
...libgis.a(put_row.o).

I corrected in main.c:
# include <math.h>
to
#include <math.h>

Maybe this helps?

src.contrib/PURDUE/d.linegraph
unresolved text symbol "log" -- 1st referenced by .. libgis.a(put_row.o)

I added in linegraph.c

#include <math.h>

NVIZ2.2
libraries are in /usr/freeware/lib32
headers are (mainly) in /usr/freeware/include
./configure works if you know the locations of libraries.

I added these paths to the search path in NVIZ2.2/configure

Thanks for your comments,

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 3623
max: 0

3

Hi Markus, hi developers,

i revisted your comments and will be more precise in what i changed.
grass5.0beta7 runs now on IRIX, apart from NVIZ2.2 and the r3.* tools.
Maybe it would be simpler if i got CVS access, but i am new to CVS and
have no experience with that.

If you have any questions or want me to test changes, please contact me
again.

> src/mapdev/v.geom:
> Unresolved text symbol "mallopt" .. libbasic.a(malloc.o).
On SuSe 6.3 I found:
/usr/include/malloc.h:extern int mallopt __MALLOC_P ((int __param, int __val));

Here is seems to be defined. No idea for you, sorry.

I _can_ compile this. See next paragraph.

> patch to Gmakefile (add ifdef for IRIX)
Mhh, once we had such ifdefs in Gmakefile. But they caused
problems on several machines.

The Gmakefile in src/mapdev/v.geom/cmd contains:
ifeq($(shell uname),IRIX64)
LIBES += -lmalloc
endif

This works _only_ on IRIX 6.5 if you are on a new 64-bit system (with
R10000 Processor).

So i _added_:

ifeq($(shell uname),IRIX)
LIBES += -lmalloc
endif

This now works for all IRIX systems, but it is a 'hack' that may cause
problems with autoconf.

> and patch to src/libes/geom/basic/malloc.c (not required!)
> The code in malloc.c (mallopt function) is not strictly required,
> it uses a feature of IRIX for debugging memory problems with malloc,
> which is only useable if you compile the library with the DEBUG flag,
> which will cause heavy performance penalties.
What do you suggest for me?

The basic library (with the malloc-wrapper) is not from grass itself. As
far as i understnad, the mallopt function is for debugging only. So it
could be removed completely to avoid the include of -lmalloc for the
above problem. But i must admit that i don't know much about malloc.
Thought until now that all modules use G_malloc. Please correct me if i
am wrong. Is someone still using the debugging feature of the
basic-library?
I commented all #ifdef SGI parts in malloc.c and recompiled, will tell
later if it works.

> src.contrib/GMSL/g3d/src3d/raster/r3.mkdspf
> unresolved text symbol "floor", "ceil", "log" etc.
> that means IMHO that $(MATHLIB) is missing in Gmakefile!
> But this $(MATHLIB) is needed at compiling of the libraries for
> g3d, i was not able to spot where to put the $(MAHTLIB) directive
> in a Gmakefile. ?
This is not possible in a lib. So I added in main.c:

#include <math.h>

Does this help for you?

no. An include statement has no effect on linking a program. If it is
not required at compile time there is no need at linking time. This is
strange: The file src/include/G3d.h is line-terminated with cr+lf like
it was edited in dos. But that should not matter.
I added $(MATHLIB) at the _end_ of the $(CC) line and now it compiles.
But now r3.showdspf.sgi crashes with lots of 'undeclared ...' and
'initializer element for ... is not constant' errors in do_color.c.
I have no clue what happens here. r3.showdspf.openGL can not be compiled
on SGI.

> src.contrib/CERL/raster/r.water.fea/src/programs/channelfea
> unresolved text symbol "log" -- 1st referenced by
> ...libgis.a(put_row.o).
I corrected in main.c:
# include <math.h>
to
#include <math.h>

Maybe this helps?

no. Most newer preprocessors accept spaces between '#' and the
statement. If you want to achieve compatibility with _very_ old
compilers it may be bad practice. I added $(MATHLIB) at the end of
LIBES= in the Gmakefile in ./channelfea and now it compiles.
$(MATHLIB) must be added to fea/Gmakefile too. Now all compiles, i will
do a check if it runs another time.

> src.contrib/PURDUE/d.linegraph
> unresolved text symbol "log" -- 1st referenced by .. libgis.a(put_row.o)
I added in linegraph.c

#include <math.h>

This is the same problem as before. $(MATHLIB) should be added as the
_last_ library, then it compiles. I guess the problem is that 'log' must
be resolved in libgis.a at the linking stage of the program. The IRIX
linker seems to be brain-damaged in a way that makes order important.

Maybe -lm (= $(MATHLIB)) should be added as the last library to _all_
modules. Does this have any bad side-effects?

> NVIZ2.2
> libraries are in /usr/freeware/lib32
> headers are (mainly) in /usr/freeware/include
> ./configure works if you know the locations of libraries.
I added these paths to the search path in NVIZ2.2/configure

I doubt that the message that is last displayed when compiling
(initializer element for 'configSpecs[9].offset' is not constant) has
anything to do with the compile error. If i change COMPILE_FLAGS to
-Wall (all warnings on) i get two more warnings before the compilation
dies (togl.c:407: warning: 'main' is usually a function).

Has anyone compiled and used TOGL on IRIX?

cu,

Andreas

--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de, A.C.Lange@GMX.net

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

4

Hi developers,

from my experience with i.ortho.photo I suggest
following small change in menu structure:

We have:
------------------------------------------------
i.ortho.photo -- Imagery Group = all

Initialization Options:

   1. Select/Modify imagery group
   2. Select/Modify imagery group target
   3. Select/Modify target elevation model
   4. Select/Modify imagery group camera

Transformation Parameter Computations:

   5. Compute image-to-photo transformation
   6. Compute ortho-rectification parameters
   7. Initialize exposure station parameters

Ortho-rectification Option:

   8. Ortho-rectify imagery files

RETURN exit
------------------------------------------------

I prefer:
------------------------------------------------
i.ortho.photo -- Imagery Group = all

Initialization Options:

   1. Select/Modify imagery group
   2. Select/Modify imagery group target
   3. Select/Modify target elevation model
   4. Select/Modify imagery group camera

Transformation Parameter Computations:

   5. Compute image-to-photo transformation
   6. Initialize exposure station parameters
   7. Compute ortho-rectification parameters

Ortho-rectification Option:

   8. Ortho-rectify imagery files

RETURN exit
------------------------------------------------

-> note that order of (6) and (7) are reversed.

Advantages:

- you will not get a warning that "exposure station parameters"
   are not set, if you first set "exposure station parameters"

- you do not get a "Matrix inversion error" from
   i.ortho.photo/libes/orthoref.c:
       error ("Matrix Inversion (Control Points status modified)");
   (my today's trap)

Disadvantages:
- I have to adjust the man page :slight_smile:
- nothing else known

Please send your comments, otherwise I may update
i.ortho.photo/menu/menu.c
the next days in CVS. This change is not very severe,
but I want to ask for agreement.

Best wishes

Markus Neteler

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'