[GRASS-dev] trouble compiling v.in.ogr on solaris

[Markus Neteler]

On Wed, May 09, 2007 at 09:20:54AM -0400, Scott Mitchell wrote:
> I'm currently trying to help some colleagues get a grass6.2 setup  
> going on a Sun sparcstation.  I got through most of the problems, but  
> am left with v.in.ogr not properly compiling.  Here's what I get from  
> a make in that dir:
> 
> eratos:~/grass-6.2.1/vector/v.in.ogr> make
> gcc -I/dat0/smitch/grass-6.2.1/dist.sparc-sun-solaris2.9/include -I/ 
> usr/local/include -I/opt/sfw/include -g -O2  -I/usr/local/include -I/ 
> opt/sfw/include  -I/usr/local/include     -DPACKAGE=\""grassmods"\"  - 
> I/usr/local/include -I/dat0/smitch/grass-6.2.1/dist.sparc-sun- 
> solaris2.9/include \
>                 -o OBJ.sparc-sun-solaris2.9/main.o -c main.c
> main.c: In function 'main':
> main.c:637: error: 'OFTDate' undeclared (first use in this function)
> main.c:637: error: (Each undeclared identifier is reported only once
> main.c:637: error: for each function it appears in.)
> make: *** [OBJ.sparc-sun-solaris2.9/main.o] Error 1
> 
> That's using GNU Make 3.81, gcc 4.0.3.
> 
> Thanks to some archive searches, I realized this could be caused by  
> having two versions of GDAL hanging around, such that the #ifdef  
> checking for a version high enough to include OFTDate doesn't  
> properly match up to the libraries found at compile-time.  And sure  
> enough, I found that in addition to the GDAL 1.4.1 I thought I was  
> using, I also found an old version 1.1.9 in a different directory  
> structure, which was also referenced in my PATH, LD_LIBRARY_PATH, and  
> even the include and lib directories I gave the grass configure.
> 
> So now I've moved the offending lib/libgdal* include/gdal* and bin/ 
> gdal* out of the way, but I still get the same error trying to  
> compile v.in.ogr - am I just being too simplistic in my attempt to  
> move out the old GDAL?  Is there another possible cause?  Is this  
> something I need to try make distclean and reconfigure for to clear  
> out the confusion (I might as well try that now, but it takes a long  
> time on this system, and I'm 95% sure I tried it already yesterday) ?

I guess that there are still old include files which disturb.
Or the conditioning fails but I thought I had tested that.

You may check which include paths are used during compilation of
v.in.ogr.

Markus