[GRASSLIST:1814] Re: grass build error: compilation error in r.in.gdal

[Glynn Clements]

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