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) ?
Thanks,
Scott
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
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