[GRASS5] Grass 5.0.0 Mac OS 10.2 Report

[Jeshua Lacock]

On Wednesday, October 9, 2002, at 08:29 AM, Glynn Clements wrote:

> 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

Yep, thanks that does the trick.

> 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).

Let me know if I can help with anything or if you would like to log in 
to take a gander.

>> 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?

Yes.  I used '--with-gdal=/usr/local/bin/gdal-config'.

>> 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

Perhaps if " -D__unix__" was added to the darwin specific configure 
script?

> 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

I tried:

[themac:~] jeshua% touch foo.c
[themac:~] jeshua% gcc -E -dM foo.c

and only got:

# 1 "foo.c"

> 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

Hmm, I am a bit confused: I grepped for LIST and make_loc.o and was not 
able to find any matches in the Gmakefile...

For now I just commented out the the __unix__ logic and it compiled 
with no errors using g++.  When I attempt to build with just gcc, I get 
the weird errors. I also tried building with the "-undefined suppress" 
with both gcc and g++. In all cases I get a binary built and the same 
error when executed:

GRASS 5.0.0 > 
/usr/src/grass-5.0.0/dist.powerpc-apple-darwin6.0/etc/bin/cmd/r.in.gdal

OPTION:   Bin raster file to be imported
      key: input
required: YES
enter option > /Users/jeshua/OSX-BG.tiff

You have chosen:
   input=/Users/jeshua/OSX-BG.tiff
Is this correct? (y/n) [y] dyld: 
/usr/src/grass-5.0.0/dist.powerpc-apple-darwin6.0/etc/bin/cmd/r.in.gdal 
Undefined symbols:
___gxx_personality_v0
__Unwind_Resume
__ZdlPv
__Znwm
__ZTVN10__cxxabiv117__class_type_infoE
__ZTVN10__cxxabiv120__si_class_type_infoE
___cxa_pure_virtual
__ZdaPv
__Znam
Trace/BPT trap

  I just tried without using the --with-gdal and it built with no 
errors, but it cannot find the library because it does not search for 
the dylib extension.

>> 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.

OK, I moved the libtcl from /usr/lib and it built without the above 
warnings. When I execute the binary it actually works now, launches the 
loading screen and dies with:

GRASS 5.0.0 > nviz -q


Version: @(#) 5.0.0 (August 2002)
[...snip...]
Adding panels from /usr/local/grass5/etc/nviz2.2/scripts
Nv_(panels)
toplevel made
child killed: bus error
     while executing
"exec /usr/local/grass5/etc/nviz2.2/NVWISH2.2 -f 
/usr/local/grass5/etc/nviz2.2/scripts/nviz2.2_script -q -name NVIZ 
 >&@stdout"
     ("eval" body line 1)
     invoked from within
"eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f 
$env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script $argv -name NVIZ 
 >&@stdout"
     invoked from within
"if {$argv == ""} {
#no arguments
eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f 
$env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script -name NVIZ >&@stdo..."
     (file "/usr/local/grass5/bin/nviz" line 16)

I had suspected that it was an issue with the Mac OS X port of Tcl/Tk 
however, I changed my wish (symbolic link) to the XFree ("unix") 
version of wish and I get the same results. Note that both versions of 
wish appear to be operational.

>> 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.

DOH! I don't know how, but I somehow overlooked this one. Yes, I never 
did get this one figured out now that you mention it.

All help is much appreciated. If someone feels compelled to take a look 
I would be grateful to pay for the time.


Thanks,

Jeshua Lacock __________________________
Programmer/Owner            Phone:   760.935.4736
http://OpenOSX.com           Fax:        760.935.4845
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_