[GRASS5] Re: compiling grass5.0beta7 on SGI IRIX
Andreas Lange
Andreas.Lange at Rhein-Main.de
Fri May 12 07:38:43 EDT 2000
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'
More information about the grass-dev
mailing list