[GRASS5] Grass 5.0.0 Mac OS 10.2 Report

[Glynn Clements]

Jeshua Lacock wrote:

> Here is my full report of my attempt to get the failed modules compiled 
> on Mac OS X 10.2.1 (Jaguar, Darwin 6.0) using gcc 3.1.
> 
> With booth d.zoom and i.pca I renamed the "round" function to "round2" 
> because it conflicted with the "round" function included with of the 
> Mac OS X math library. Both modules test out OK.

The round() problem is known, and has been fixed in CVS.

> The module g.region fails with E_edit_cellhd as an undefined symbol.
> 
> The v.reclass, r.weight and r.reclass modules all fail with 
> _E_edit_cats as an undefined symbol.
> 
> While building "src/raster/r.support", in addition to missing 
> _E_edit_cats, I get another undefined symbol:
> 
> /usr/bin/ld: Undefined symbols:
> _E_edit_cats
> _E_edit_fp_cats
> 
> E_edit_cellhd, E_edit_cats  and E_edit_fp_cats  are all defined in 
> src/include/edit.h. Suspicious?

This is because MacOS has it's own "edit" library (libedit.dylib), and
it uses this in preference to GRASS' version (libedit.a, built from
src/libes/edit). The quick fix is to change src/CMD/generic/make.mid
thus:

	DEPEDITLIB     = $(LIBDIR)/libgedit.a
	EDITLIB        = -lgedit

This has been fixed in CVS; however, in the longer term, we need to
figure out how to force the Mac's linker to resolve any name conflicts
in favour of the package's library (most systems will use GRASS'
libedit.a regardless of whether there are any similarly-named
libraries installed elsewhere, due to the -L switches).

> While attempting to build r.in.gdal I get some strange undefined 
> symbols:
> 
> /usr/bin/ld: Undefined symbols:
> _GBGetSymbol
> ___gxx_personality_v0
> __Unwind_Resume
> __ZdlPv
> __Znwm
> __ZTVN10__cxxabiv117__class_type_infoE
> __ZTVN10__cxxabiv120__si_class_type_infoE
> ___cxa_pure_virtual
> __ZdaPv
> __Znam

I haven't seen this before, but it is definitely C++ related. However,
while libgdal is written in C++, r.in.gdal isn't. Are you using
configure's --with-gdal switch?

> A google search indicated that this could be a symptom of using cc 
> instead of c++, so I used g++ instead of gcc and just get:
> 
> ld: Undefined symbols:
> _GBGetSymbol

Also a known problem; there are two versions of this function in
gbgetsymbol.c. The first is conditionalised upon:

	#if defined(__unix) || defined(__unix__)

while the second is conditionalised upon:

	#ifdef _WIN32

You need to add something to the first of these so that the code is
enabled on MacOSX. Running "gcc -E -dM" on an empty ".c" file should
produce a list of the macros which are defined by default. E.g. on
Linux/x86:

	$ touch foo.c
	$ gcc -E -dM foo.c 
	#define __linux__ 1 
	#define linux 1 
	#define __i386__ 1 
	#define __tune_i386__ 1 
	#define __i386 1 
	#define __GNUC_MINOR__ 91 
	#define i386 1 
	#define __unix 1 
	#define __unix__ 1 
	#define __GNUC__ 2 
	#define __linux 1 
	#define __ELF__ 1 
	#define unix 1 

Note that this code (gbgetsymbol.c and gdalbridge.c) isn't actually
used if you use "--with-gdal". Unfortunately, it *is* still compiled.

If you use --with-gdal, try manually removing these files from the
Gmakefile, i.e.

	LIST   = main.o make_loc.o

> The last failed module is NVIZ2.2:
> 
> In file included from nvizAppInit.c:9:
> interface.h:257: conflicting types for `Tk_SetAppName'
> /usr/local/include/tkDecls.h:573: previous declaration of 
> `Tk_SetAppName'
> make[1]: *** [OBJ.powerpc-apple-darwin6.0/nvizAppInit.o] Error 1
> make: *** [nvwish] Error 2
> 
> So I commented out  "char *Tk_SetAppName(Tk_Window, char *);" from 
> interface.h and  I got:
> 
> togl.c:161: header file 'tkInt8.4.h' not found
> 
> So I tried copying tkInt.h to tkInt8.4.h
> 
> It then built with some warnings:
> init_commands.c: In function `init_commands':
> init_commands.c:131: warning: passing arg 3 of `Tcl_CreateCommand' from 
> incompatible pointer type
> init_commands.c: ....
> ....for all lines that use "Tcl_CreateCommand"

These warnings are harmless.

> nviz_init.c: In function `Ngetargs':
> nviz_init.c:303: warning: assignment discards qualifiers from pointer 
> target type
> nviz_init.c:304: warning: assignment discards qualifiers from pointer 
> target type
> [...snip...]
> togl.c: In function `Togl_Init':
> togl.c:729: warning: passing arg 3 of `Tcl_CreateCommand' from 
> incompatible pointer type
> togl.c: In function `Togl_Cmd':
> togl.c:1179: warning: passing arg 3 of `Tcl_CreateCommand' from 
> incompatible pointer type
> [...snip...]

These may not be harmless.

> /usr/bin/ld: warning multiple definitions of symbol _tclPlatStubsPtr
> /usr/lib/libtcl.dylib(tclStubLib.o) definition of _tclPlatStubsPtr
> /usr/local/lib/libtk8.4.dylib(tclStubLib.o) definition of _tclPlatStubsPtr

This doesn't look good. Normally, one would expect libtcl and libtk to
be in the same place (e.g. both in /usr/lib or both in
/usr/local/lib), and that either both would be versioned or that
neither would be versioned.

Also, if you have multiple versions of Tcl/Tk, NVIZ needs the generic
Unix/X11 versions rather than a Mac version. The same applies to
OpenGL, BTW.

> When I attempt to run NVIZ I get:
> 
> GRASS 5.0.0 > nviz
> child killed: SIGABRT

If it's linked against incompatible Tcl/Tk libraries, I would expect
some form of low-level error (such as dying due to SIGABRT, SIGBUS,
SIGSEGV).

> Everything else seems to work great - excellent work!

Odd; others have also reported problems with src/libes/vect32/georef,
due to undefined symbols ax, ay, bx, by, etc.

> Any help would be greatly appreciated! I am willing to hire someone to 
> log-on and take a look...

Most of these issues have been found and fixed (or worked around)
since the release. The NVIZ issue might be resolved by adding more
configure switches, e.g.

	--with-tcltk-includes=/usr/local/include
	--with-tcltk-libs=/usr/local/lib
	--with-opengl-includes=/usr/X11R6/include
	--with-opengl-libs=/usr/X11R6/lib

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