[gdal-dev] GDAL compiler & GDAL utility use

[Randy]

Hi Peter,
Thank you so so much for your response!
I still believe there is something wrong with my GDAL compiling or environment variable.
I use ogrinfo(one of GDAL/OGR utilities) in GDAL on my Linux & Windows OS, the result is the same(wrong):
->Ogrinfo -ro -al -q US5TX51M.000 |more
ERROR 1:Invalid index :-1
ERROR 1:Invalid index :-1
ERROR 1:Invalid index :-1
ERROR 1:Invalid index :-1
//...a lot as the same as above
Layer name: DSID
...
Layer name:Point
.....
Layer name:Line
..........

While the ogrinfo in FWTools ,the result is as follows:
Layer name: DSID
...
Layer name: ACHARE
...
Layer name: BCNLAT
...

Then, I'd like to know what else I should do when I build GDAL in a default way:
cd 
./configure
./make
./sudo make install
What I do else until now is just set GDAL_DATA environment variable and OGR_S57_OPTIONS. And I use GDAL1.7.2 release version.

Best regards,
Randy
-----Original Message-----
From: Peter J Halls [mailto:P.Halls at york.ac.uk] 
Sent: Thursday, June 17, 2010 4:54 PM
To: randy
Subject: [!! SPAM] Re: [gdal-dev] problem on function "OGR_FD_GetName"

Randy,

    I've not worked with your platforms but, extrapolating from my 
Solaris(Sparc) environment ...

    GDAL uses Environment Variables as an alternative to the configure script 
parameter list.  I'm old fashioned here and prefer the parameter list, as I find 
it easier to debug.  Having said that, these control things like the compiler to 
use and the additional libraries to configure: I do not think any of these are 
likely to affect the way OGR_FD_GetName works.  Are you using the same hardware 
environment with different operating systems?  Has Configure correctly 
determined the hardware environment?  You can work through Config.status and 
Config.log to check this - if the two GDAL environments are supposed to be the 
same, can you diff these as a quick way of finding any differences?

    There are also a few Environment Variables involved at runtime eg PATH, 
LD_LIBRARY_PATH, ORACLE_HOME, TNS_ADMIN, and so on.  The last two control the 
Oracle interface; the first two affect loading a program at runtime.  If any of 
these are wrong, I would not expect execution to start or get as far as you 
have.  On that basis, I think it unlikely that you have an Environment variable 
problem.

    I presume that you are reading the same file on each platform?  The 'new' 
results you are reporting look to me as though the data definition is being 
reported instead of the feature name: could it be that you are effectively 
reading alternate lines?  Do you have a problem prior to calling OGR_FD_GetName 
that may be reading the next entry in the dataset to fulfil the input request 
and thus giving the impression of the incorrect feature name?  This could come 
back to the GDAL Configure results, prior to building GDAL.  [Did you transfer 
the GDAL source directory from one platform to the other?  If so, did you run a 
'make clean' before building GDAL on the second, problematic platform?  It is 
possible for bits of an old configuration to 'linger' if the clean is not run ...]

Hoping there is something there that helps,

Best wishes,

Peter

-----------------------