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

[Scott Mitchell]

On 9-May-07, at 09:44 , Markus Neteler wrote:

> 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.

That was it, yes, thanks.  I knew the paths involved, but reading the  
actual #include lines in the source files was the key to finding the  
extra .h files to move out.  Problem solved.

Cheers,
Scott