[GRASS5] Re: compiling grass5.0beta7 on SGI IRIX

[Andreas Lange]

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 at Rhein-Main.de, A.C.Lange at GMX.net

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