[GRASS5] Grass 5.0.0 Mac OS 10.2 Report
Jeshua Lacock
jeshua at OpenOSX.com
Thu Oct 10 07:35:52 EDT 2002
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
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
More information about the grass-dev
mailing list