[GRASS5] Grass 5.0.0 Mac OS 10.2 Report

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