[GRASS5] Grass 5.0.0 Mac OS 10.2 Report

[Jeshua_Lacock]

Greetings,

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

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

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

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"

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...]
/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
/usr/bin/ld: warning multiple definitions of symbol _tclIntStubsPtr
/usr/lib/libtcl.dylib(tclStubLib.o) definition of _tclIntStubsPtr
/usr/local/lib/libtk8.4.dylib(tclStubLib.o) definition of _tclIntStubsPtr
/usr/bin/ld: warning multiple definitions of symbol _Tcl_InitStubs
/usr/lib/libtcl.dylib(tclStubLib.o) definition of _Tcl_InitStubs
/usr/local/lib/libtk8.4.dylib(tclStubLib.o) definition of _Tcl_InitStubs
/usr/bin/ld: warning multiple definitions of symbol _tclIntPlatStubsPtr
/usr/lib/libtcl.dylib(tclStubLib.o) definition of _tclIntPlatStubsPtr
/usr/local/lib/libtk8.4.dylib(tclStubLib.o) definition of _tclIntPlatStubsPtr
/usr/bin/ld: warning multiple definitions of symbol _tclStubsPtr
/usr/lib/libtcl.dylib(tclStubLib.o) definition of _tclStubsPtr
/usr/local/lib/libtk8.4.dylib(tclStubLib.o) definition of _tclStubsPtr
/usr/bin/ld: warning suggest use of -bind_at_load, as lazy binding may result in errors or different symbols being used
symbol _tclIntPlatStubsPtr used from dynamic library /usr/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library /usr/local/lib/libtk8.4.dylib(tclStubLib.o)
symbol _Tcl_InitStubs used from dynamic library /usr/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library /usr/local/lib/libtk8.4.dylib(tclStubLib.o)
symbol _tclStubsPtr used from dynamic library /usr/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library /usr/local/lib/libtk8.4.dylib(tclStubLib.o)
symbol _tclPlatStubsPtr used from dynamic library /usr/lib/libtcl.dylib(tclStubLib.o) not from earlier dynamic library /usr/local/lib/libtk8.4.dylib(tclStubLib.o)

When I attempt to run NVIZ I get:

GRASS 5.0.0 > nviz
child killed: SIGABRT
     while executing
"exec /usr/local/grass5/etc/nviz2.2/NVWISH2.2 -f /usr/local/grass5/etc/nviz2.2/scripts/nviz2.2_script -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 -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)

So I tried:

GRASS 5.0.0 > eval exec /usr/local/grass5/etc/nviz2.2/NVWISH2.2 -f /usr/local/grass5/etc/nviz2.2/scripts/nviz2.2_script
/usr/local/grass5/etc/Init.sh: line 517: 20182 Abort trap $ETC/run $SHELL

Cleaning up temporary files.....
done

Goodbye from GRASS GIS

[themac:~] jeshua%

And it quits me right out of Grass!

Everything else seems to work great - excellent work!

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

Thanks,

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

[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@virgin.net>

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

[Glynn_Clements]

Jeshua Lacock wrote:

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

Another MacOSX user sent me a copy of the linker's man page, which
seems to suggest that the behaviour can't be changed (i.e. a ".dylib"
always takes preference over a ".a", regardless of their locations or
any "-L" switches).

AFAICT, the only robust solution is for all GRASS libraries to be
named "libgrass_foo.a" rather than just "libfoo.a".

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

Note that gdalbridge.c and gbgetsymbol.c aren't actually used if you
use --with-gdal. They are, however, compiled, and gdalbridge.o will
complain about the absence of GBGetSymbol(), even though gdalbridge.o
is unused.

Both of those files should probably have their contents
conditionalised upon:

  #ifndef USE_GDAL_H

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

One of the documents which I have implies that the Mac includes its
own preprocessor in addition to gcc's, and that the Mac-specific one
is use by default. See if you can change this (the document only
refers to -no-cpp-precomp, which seems like it might be specific to
pre-compiled headers).

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

The file in question is:

  src/raster/r.in.gdal/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

This looks like a C++ issue. I would suggest building main.c with g++
instead of gcc, but it includes headers which aren't compatible with
C++ (e.g. "struct Cluster" in imagery.h has a field called "class").

  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.

Even if it can find it, it might not actually be able to use it, due
to the C++ issues.

I'm starting to suspect that there won't a simple fix for r.in.gdal.
At least nothing else in GRASS uses C++. Just remember to complain the
next time that anyone suggests permitting the use of C++ in GRASS.

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

Again, a low-level error; the NVWISH2.2 binary dies suddenly. This one
probably needs a debugger to track down.

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

When the Mac's linker links against libgeo.a, it ignores the file
vars.o which defines these symbols (probably because the file only
defines variables, not functions).

The simplest workaround is to link against vars.o manually, i.e.
change "libgeo.a" to "vars.o libgeo.a" in
src/libes/vect32/georef/Gmakefile, e.g.

$(ETC)/geo.reg: bin_reg.o $(DEPGISLIB) $(DEPLOCKLIB)
  $(CC) $(LDFLAGS) -o $(ETC)/geo.reg bin_reg.o vars.o libgeo.a $(GISLIB) $(LOCKLIB) $(MATHLIB) $(XDRLIB)

Similarly for the other three targets.

I've moved the variables to geo_file.c in the CVS head, so this should
also be fixed in 5.0.1.

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

[neteler]

On Thu, Oct 10, 2002 at 05:08:56PM +0100, Glynn Clements wrote:
[...]

AFAICT, the only robust solution is for all GRASS libraries to be
named "libgrass_foo.a" rather than just "libfoo.a".

This may be a good idea in any case (also solves problems in case
the GRASS libs go somewhere into the system's standard lib directories).

Markus