Jeshua,
I'm a C++ (GNU/g++, Slackware-8.0 Linux, Intel box) developer and a
longtime user of GRASS (since the early 4.0 days, at least).
The GRASS list hasn't addressed many of the issues involved in getting
an application to build using GNU/g++ (C++), AFAICT. I've recently had
to resolve some of the problems you are facing when compiling and linking
GRASS libraries with C++. Perhaps my experience in this will help you
with your particular problem.
I recently wrote an application to translate some weather radar
reflectivity data into a GRASS raster format to use as input for
another GRASS application. I wanted to incorporate some of my favorite
C++ utilities as well as make use of the GRASS functions in the
'libgis' library to help me correctly format my radar data.
Because the C++ compiler 'mangles' (changes) the names of symbol
references differently than the 'C' (gcc) compiler, I found that the
following simple construct allowed me to make calls to GRASS library
functions from my C++ application.
In the header section of the source code file (or better in a header
file), wrap the "#include gis.h" declaration with an "extern C"
directive, as in the following example:
extern "C" {
#include "gis.h"
}
What this does is to tell the C++ compiler that 'C' naming protocols are
used for these symbols, and allows the linker to find the referenced
functions, data structures, or variables in the 'C' compiled libraries.
You may need to include other header file names in the extern "C"
directive that also have been compiled using the 'C' compiler, because
of the name mangling differences between compilers.
From your included documentation, I'd try adding
extern "C" {
include "tk.h"
include "interface.h"
}
(and possibly other include files that reference functions in 'C'
compiled libraries) to all the.c source files you are compiling with
C++.
I hope this helps and feel free to ask about details that I haven't
made very clear in this brief synopsis of how I build applications
using a C++ compiler.
Kind Regards,
Scott O'Donnell
BTW,
Thanks for your quick service. I recently ordered Marcus' & Helena's
book from OpenOSX.com and received it sooner than expected.
---
grass5-request@grass.itc.it wrote:
Message: 10
Date: Tue, 8 Oct 2002 20:26:14 -0700
From: Jeshua Lacock <jeshua@OpenOSX.com>
To: grass5 list <grass5@grass.itc.it>
Subject: [GRASS5] Grass 5.0.0 Mac OS 10.2 ReportGreetings,
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_catsE_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
__ZnamA 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:
_GBGetSymbolThe 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 2So 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 $SHELLCleaning up temporary files.....
doneGoodbye 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
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-________________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5End of grass5 Digest
--
Reality is that which, when you stop believing | Scott O'Donnell
in it, doesn't go away. -- Philip K. Dick | odonnell@peakpeak.com
| odonnell@fsl.noaa.gov
| 303·497·6562