[GRASS5] r.in.gdal compile problem

Hello

William K wrote:

With GRASS 5.0.3 CVS (7-19 and a couple earlier versions) I can't get
r.in.gdal to compile. I get an illegal indirect reference from libgis
to libgrass:

gcc
-L/Users/williamk/Documents/src/unix/GRASS/grass50_exp_2003_06_28/src/
libes/LIB.powerpc-apple-darwin6.6 -o
/Users/williamk/Documents/src/unix/GRASS/grass50_exp_2003_06_28/
dist.powerpc-apple-darwin6.6/etc/bin/cmd/r.in.gdal
OBJ.powerpc-apple-darwin6.6/main.o
OBJ.powerpc-apple-darwin6.6/gbgetsymbol.o
OBJ.powerpc-apple-darwin6.6/gdalbridge.o
OBJ.powerpc-apple-darwin6.6/make_loc.o \
         -L/usr/local/lib -lgdal.1.1 -lgeotiff -ltiff -lgproj
-L/usr/local/lib -lproj -lgis -lintl -lI -lz
ld:
/Users/williamk/Documents/src/unix/GRASS/grass50_exp_2003_06_28/src/
libes/LIB.powerpc-apple-darwin6.6/libgis.a(color_rule.o) illegal
reference to symbol: _G__color_free_fp_lookup defined in indirectly
referenced dynamic library /usr/local/lib/libgrass5.0.dylib

It looks like you have GDAL compiled with external GRASS support and it
is looking in the libgrass5 library. Looks like that can get a bit
complicated if you are using GDAL directly with GRASS, so maybe try
compiling GDAL without this (--with-grass=no as a configure script
option---but this should be the default).

ld: warning multiple definitions of symbol _CSVGetFileFieldId
/usr/local/lib/libgdal.1.1.dylib(cpl_csv.o) definition of
_CSVGetFileFieldId
/usr/local/lib/libgeotiff.dylib(cpl_csv.o) definition of
_CSVGetFileFieldId

I can only suggest to not use an external tiff library when compiling
GDAL and use the GDAL internal tiff (--with-libtiff=internal
--with-geotiff=internal or something similar). I think I read somewhere
there are problems using external tiff libraries with GDAL?

I'm not sure if this is the best way to fix the problems but it might be
a workaround.

Paul

make[1]: ***
[/Users/williamk/Documents/src/unix/GRASS/grass50_exp_2003_06_28/
dist.powerpc-apple-darwin6.6/etc/bin/cmd/r.in.gdal] Error 1
GISGEN failure at STEP: src/raster/r.in.gdal

I've tried reordering the LIBES libs, and GDAL_LIBS & LIBES, in the
GMakefile for r.in.gdal, but that just causes other indirect
references. This is beyond my porting experience so far to know what
it means and how to fix it.

-----
William Kyngesburye <kyngchaos@charter.net>
http://webpages.charter.net/kyngchaos/

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin
RIP Douglas Adams 1952-2001

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

On Sat, Aug 09, 2003 at 10:37:59AM +0100, Paul Kelly wrote:

I can only suggest to not use an external tiff library when compiling
GDAL and use the GDAL internal tiff (--with-libtiff=internal
--with-geotiff=internal or something similar). I think I read
somewhere there are problems using external tiff libraries with GDAL?

The only problem is that GDAL requires the latest libtiff version
(3.6.0beta2 currently). If you have suitable libtiff installation
configure script should determine and use it automatically, otherwise
internal version will be selected. It should not be any other problems
with libtiff.

          Regards,
          Andrey

--
Andrey V. Kiselev
Home phone: +7 812 5274898 ICQ# 26871517