[GRASSLIST:3770] unable to initialize GDAL bridge

Hi, I’m a grass beginner and am running into a problem with r.in.gdal. Whenever I try to import a file, I receive the following error:

GBBridgeInitialize() failed to find an suitable GDAL .DLL/.so file.
The following filenames were searched for:
o libgdal.1.1.so
o gdal.1.0.so
o gdal.so.1.0
o libgdal.so.1

The following locations were searched:
o /usr/local/grass53/lib
o System default locations.

ERROR: Unable to initialize GDAL bridge (check libgdal
installation/LD_LIBRARY_PATH variable).
mail: not found

I am running Grass53 in Cygwin in Windows XP Pro. The version of GDAL that I built from source is 1.2.1. Thanks in advance.

Grant

Grant Yip wrote:

Hi, I'm a grass beginner and am running into a problem with
r.in.gdal. Whenever I try to import a file, I receive the following error:

GBBridgeInitialize() failed to find an suitable GDAL .DLL/.so file.

[snip]

I am running Grass53 in Cygwin in Windows XP Pro. The version of GDAL that
I built from source is 1.2.1. Thanks in advance.

On Cygwin, you have to use the --with-gdal configure switch.

--
Glynn Clements <glynn.clements@virgin.net>

Glynn, I didn’t compile Grass53, I installed Grass53 using the binary from Rich Greenwood’s site. Is there a solution for the binary install?

On a side note, I installed Grass53 from binary because I wasn’t able to compile it from source. The ‘./cofigure’ command worked fine but was never able use the ‘make’ command. I just received an error stating that there was nothing to make.

thanks,
Grant

At 02:45 PM 6/28/2004, Glynn Clements wrote:

Grant Yip wrote:

Hi, I’m a grass beginner and am running into a problem with
r.in.gdal. Whenever I try to import a file, I receive the following error:

GBBridgeInitialize() failed to find an suitable GDAL .DLL/.so file.

[snip]

I am running Grass53 in Cygwin in Windows XP Pro. The version of GDAL that
I built from source is 1.2.1. Thanks in advance.

On Cygwin, you have to use the --with-gdal configure switch.


Glynn Clements glynn.clements@virgin.net

Grant Yip wrote:

Glynn, I didn't compile Grass53, I installed Grass53 using the binary from
Rich Greenwood's site. Is there a solution for the binary install?

No. If r.in.gdal gives that error message, it has been mis-compiled.

On a side note, I installed Grass53 from binary because I wasn't able to
compile it from source. The './cofigure' command worked fine but was never
able use the 'make' command. I just received an error stating that there
was nothing to make.

Odd. What does the Makefile look like?

--
Glynn Clements <glynn.clements@virgin.net>

At 04:57 PM 6/28/2004, Glynn Clements wrote:

Odd. What does the Makefile look like?

Actually, it wouldn’t make it past ‘./configure’. the program goes through a series of ‘checking for…’ messages and stops at the following message ‘configure: error: ***Unable to locate ODBC library’ at which time it jumps to the command prompt. I cannot go any further at this point and cannot enter the make or make install commands…

I have the required libraries listed on the GRASS REQUIREMENTS page, including unixodbc2, which I guess is the ODBC library the program cannot find. Do you have any suggestions for getting around this error so that I can compile from source?

Grant

Grant Yip
Department of Geological Sciences
Webb Hall - Building 526
University of California
Santa Barbara, CA
93106-9630
(805)893-2782
Grad Shack

www.uweb.ucsb.edu/~yip

Grant Yip wrote:

>Odd. What does the Makefile look like?

Actually, it wouldn't make it past './configure'. the program goes through
a series of 'checking for...' messages and stops at the following message
'configure: error: ***Unable to locate ODBC library' at which time it jumps
to the command prompt. I cannot go any further at this point and cannot
enter the make or make install commands..

I have the required libraries listed on the GRASS REQUIREMENTS page,
including unixodbc2, which I guess is the ODBC library the program cannot
find. Do you have any suggestions for getting around this error so that I
can compile from source?

Use --without-odbc to disable the ODBC checks and the programs which
use ODBC (none of which are particularly important).

--
Glynn Clements <glynn.clements@virgin.net>

On Mon, 28 Jun 2004, Grant Yip wrote:

Glynn, I didn't compile Grass53, I installed Grass53 using the binary from Rich Greenwood's site. Is there a solution for the binary install?

I have some GRASS 5.3.0 Cygwin binaries that I think have shared GDAL (dll), proj dll and NVIZ all working. Not confident enough to put them on the GRASS website though and I don't have my own ftp site. If you or somebody else could provide an ftp server I could upload them to it would be good to try them.

Paul K

This is a follow-up to my problem with GDAL and installing a functional GRASS53 for cygwin on a windows xp pro os.

I followed everyone’s suggestions about compiling GRASS53 without ODBC and other checks that were giving me errors, these included proj and FFTW. Compiling from source took a while and it finished without fanfare (i.e. it didn’t give me a ‘welcome to grass53 message and type grass53 to begin’ that i recalled seeing with the binaries). The GDAL function finally worked but nviz stopped working. GRASS gave me the following error:

Can’t find a usable init.tcl in the following directories:
F:/cygwin/share/tcl8.4 F:/cygwin/usr/local/grass53/etc/share/tcl8.4 etc…

This probably means that Tcl wasn’t installed properly.

can’t read “src_boot” no such variable while executing
“source &src_boot/etc/nviz2.2/scripts/config.tcl”
(file “/usr/local/grass53/etc/nviz2.2/scripts/nviz2.2_script” line 21)

Then GRASS lists the following error:

child process exited abnormally
while executing
“exec /usr/local/grass53/etc/nviz2.2/NVWISH2.2 -f /usr/local/grass53/etc/nviz2.2./scripts/nviz2.2_script -q -name NVIZ >&@stdout
(“eval” body line 1)
invoked from within
“eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script $argv -name NVIZ >&@stdout
invoked from within
"if {$argv == “”} {
#no arguments
eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script -name NVIZ >&@stdo…"
(file “/usr/local/grass53/bin/nviz” line 16)

It appeared that GRASS was looking for files in folders that didn’t exist and in an older GRASS directory that I installed from a binary (the version for GRASS53 I compiled from source went to a directory named grass-5.3.0, not grass53). I decided that I probably needed a fresh start since I had been trying to install GRASS and it’s libraries for a week or so and may have files placed in directories all over the place.

I uninstalled and deleted previous installations of GRASS and Cygwin. I then reinstalled Cygwin from scratch and the newly posted GRASS53 binary (6-29-2004) from www.greenwoodmaps.com, and the tcltk8.3.4 binary from the GRASS website and built gdal-1.2.1 from source from www.remotesensing.org/gdal. GRASS53 now appears to be working fine without any errors.

thanks for the help.

grant

On a sidenote, there doesn’t appear to be a link from the official GRASS website or it’s mirrors to the GRASS53 Cygwin binary even though the directory exists. I don’t know if this is intentional since it is a CVS or an oversight (http://grass.itc.it/grass53/binary/mswindows_cygwin/).

At 10:36 PM 6/28/2004, Glynn Clements wrote:

Grant Yip wrote:

Odd. What does the Makefile look like?

Actually, it wouldn’t make it past ‘./configure’. the program goes through
a series of ‘checking for…’ messages and stops at the following message
‘configure: error: ***Unable to locate ODBC library’ at which time it jumps
to the command prompt. I cannot go any further at this point and cannot
enter the make or make install commands…

I have the required libraries listed on the GRASS REQUIREMENTS page,
including unixodbc2, which I guess is the ODBC library the program cannot
find. Do you have any suggestions for getting around this error so that I
can compile from source?

Use --without-odbc to disable the ODBC checks and the programs which
use ODBC (none of which are particularly important).


Glynn Clements glynn.clements@virgin.net