Kirk R. Wythers wrote:
>> here is the whole section concerning gdal:
>>
>> #################################################################
>> /Users/kirkw/tmp/grass-5.0.3/src/raster/r.in.dted/r.in.dted
>> make -f OBJ.powerpc-apple-darwin7.0.0/make.rules
>>
>> make[1]: Nothing to be done for `all'.
>>
>> GISGEN: src/raster/r.in.gdal - Tue Nov 18 13:28:49 CST 2003
>>
>> #################################################################
>> /Users/kirkw/tmp/grass-5.0.3/src/raster/r.in.gdal
>> make -f OBJ.powerpc-apple-darwin7.0.0/make.rules
>>
>> gcc
>> -L/Users/kirkw/tmp/grass-5.0.3/src/libes/LIB.powerpc-apple-darwin7.0.0
>> -L/sw/lib -o
>> /Users/kirkw/tmp/grass-5.0.3/dist.powerpc-apple-darwin7.0.0/etc/bin/
>> cmd/r.in.gdal OBJ.powerpc-apple-darwin7.0.0/main.o
>> OBJ.powerpc-apple-darwin7.0.0/gbgetsymbol.o
>> OBJ.powerpc-apple-darwin7.0.0/gdalbridge.o
>> OBJ.powerpc-apple-darwin7.0.0/make_loc.o
>> /usr/local/lib/gdal.a /usr/local/lib/ogr.a
>> /usr/local/lib/gdal.a /usr/local/lib/cpl.a -lm -ldl -lm -lproj -lgis
>> -lintl -lI -lz
>> ld: table of contents for archive: /usr/local/lib/gdal.a is out of
>> date; rerun ranlib(1) (can't load from it)
>> ld: table of contents for archive: /usr/local/lib/ogr.a is out of
>> date;
>> rerun ranlib(1) (can't load from it)
>> ld: table of contents for archive: /usr/local/lib/gdal.a is out of
>> date; rerun ranlib(1) (can't load from it)
>> ld: table of contents for archive: /usr/local/lib/cpl.a is out of
>> date;
>> rerun ranlib(1) (can't load from it)
>
> This suggests a problem with building the GDAL libraries
This is the output from each ranlib:
>
> Try:
> ranlib /usr/local/lib/gdal.a
barbaloot:~/tmp/grass-5.0.3 kirkw$ sudo ranlib /usr/local/lib/gdal.a
Password:
ranlib: file: /usr/local/lib/gdal.a(pnggccrd.o) has no symbols
ranlib: file: /usr/local/lib/gdal.a(pngvcrd.o) has no symbols
ranlib: file: /usr/local/lib/gdal.a(tif_pixarlog.o) has no symbols
ranlib: file: /usr/local/lib/gdal.a(cpl_vsil_unix_stdio_64.o) has no
symbols
> ranlib /usr/local/lib/ogr.a
barbaloot:~/tmp/grass-5.0.3 kirkw$ sudo ranlib /usr/local/lib/ogr.a
ranlib: file: /usr/local/lib/ogr.a(ogrsurface.o) has no symbols
> ranlib /usr/local/lib/cpl.a
barbaloot:~/tmp/grass-5.0.3 kirkw$ sudo ranlib /usr/local/lib/cpl.a
ranlib: file: /usr/local/lib/cpl.a(cpl_vsil_unix_stdio_64.o) has no
symbols
That shouldn't be a problem; these should just be warnings. Depending
upon the GDAL build options, those .o files may well be empty.
As the "rerun ranlib(1)" messages are absent from your latest attempt,
that particular problem appears to have been fixed.
Same outcome in that gdal did not compile with grass. But, new errors
in the make process:
GISGEN: src/raster/r.in.gdal - Tue Nov 18 18:35:14 CST 2003
#################################################################
/Users/kirkw/tmp/grass-5.0.3/src/raster/r.in.gdal
make -f OBJ.powerpc-apple-darwin7.0.0/make.rules
gcc
-L/Users/kirkw/tmp/grass-5.0.3/src/libes/LIB.powerpc-apple-darwin7.0.0
-L/s\
w/lib -o
/Users/kirkw/tmp/grass-5.0.3/dist.powerpc-apple-darwin7.0.0/etc/bin/cm\
d/r.in.gdal OBJ.powerpc-apple-darwin7.0.0/main.o
OBJ.powerpc-apple-darwin7.0.0/\
gbgetsymbol.o OBJ.powerpc-apple-darwin7.0.0/gdalbridge.o
OBJ.powerpc-apple-darw\
in7.0.0/make_loc.o \
/usr/local/lib/gdal.a /usr/local/lib/ogr.a
/usr/local/lib/gdal.a /usr/l\
ocal/lib/cpl.a -lm -ldl -lm -lproj -lgis -lintl -lI -lz
ld: Undefined symbols:
___gxx_personality_v0
operator delete(void*)
operator new(unsigned long)
vtable for __cxxabiv1::__class_type_info
vtable for __cxxabiv1::__si_class_type_info
___cxa_pure_virtual
operator delete(void*)
operator new(unsigned long)
OK. I believe that this is because you need some additional switches
when linking against C++ code (most of GDAL is C++).
It may suffice to replace "gcc" with "g++" in the link command. Either
by running the above command manually, but substituting "g++" for
"gcc", or by editing src/raster/r.in.gdal/Gmakefile, changing $(CC) to
"g++".
Typically, there would be a standard library (or even a simple object
file) which defines the above symbols, and using g++ as the linker
will use that library (or object file) automatically.
E.g. on Linux, C++ programs use libstdc++. Linking with "g++"
automatically implies "-lstdc++"; if you link with "gcc", you have to
explicitly add "-lstdc++" to the link command.
Note: this issue doesn't normally arise for shared libraries, as they
typically include dependency information, so the linker will add any
dependent libraries automatically.
I suppose that the gdal-config script should really deal with this.
--
Glynn Clements <glynn.clements@virgin.net>