-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
installing the new version of GRASS (20-11) I see that there is a new needed
library (libogdi31.so) that is available only for Mandrake.
Is it a truly needed library or only a bug in the binary of the week?
The library seems avalaible only for Mandrake and it is aproblem for all other
linux distribution.
Thanks
Leonardo
- --
Leonardo Lami
lami@faunalia.it www.faunalia.it
Via Colombo 3 - 51010 Massa e Cozzile (PT), Italy Tel: (+39)349-1310164
GPG key @: hkp://wwwkeys.pgp.net http://www.pgp.net/wwwkeys.html
https://www.biglumber.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBohhl92hCyP73w7ARAlchAKCc59F1UTTd9Nmm7NGbbPlGH95BMwCaAgdT
QG7swIeTZ+k+mMElBkp8I/w=
=cdTW
-----END PGP SIGNATURE-----
Leonardo Lami wrote:
installing the new version of GRASS (20-11) I see that there is a new needed
library (libogdi31.so) that is available only for Mandrake.
Is it a truly needed library or only a bug in the binary of the week?
Probably the latter. Which programs/libraries require it?
--
Glynn Clements <glynn@gclements.plus.com>
GDAL compiled with OGDI.
Em Seg 22 Nov 2004 17:08, Glynn Clements escreveu:
Leonardo Lami wrote:
> installing the new version of GRASS (20-11) I see that there is a new
> needed library (libogdi31.so) that is available only for Mandrake.
> Is it a truly needed library or only a bug in the binary of the week?
Probably the latter. Which programs/libraries require it?
--
Instituto IGARÉ
http://geocities.yahoo.com.br/institutoigare
e-mail: institutoigare@yahoo.com.br
Sandro Klippel wrote:
> > installing the new version of GRASS (20-11) I see that there is a new
> > needed library (libogdi31.so) that is available only for Mandrake.
> > Is it a truly needed library or only a bug in the binary of the week?
>
> Probably the latter. Which programs/libraries require it?
GDAL compiled with OGDI.
In that case, it should only be an issue for the GDAL library. Delete
the libgdal binary which came with GRASS (from $GISBASE/lib) and
install one which is compatible with your system.
Given the large number of possible dependencies for GDAL, the chances
of a libgdal binary built for one system is working on another system
are low. It doesn't help that GDAL's configure script insists on
autodetecting everything; you have to explicitly provide --without-*
switches for any libraries which you don't want to use.
Probably the simplest solution is to either build GDAL yourself from
source code, or install your OS vendor's "official" GDAL package (if
they have one), along with all of the necessary dependencies (package
management tools such as RPM will either do this for you or at least
tell you what you need to install).
--
Glynn Clements <glynn@gclements.plus.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Note however that this is the first time we see that problem.
With previous GRASS versions everythig's ok.
GRASS form binaries (not compiled) on a Debian Sarge box, with GDAL from
Debian package.
Markus, perhaps something went wrong during the compilation?
Thanks.
pc
At 02:45, martedì 23 novembre 2004 you presumably wrote:
Sandro Klippel wrote:
> > > installing the new version of GRASS (20-11) I see that there is a new
> > > needed library (libogdi31.so) that is available only for Mandrake.
> > > Is it a truly needed library or only a bug in the binary of the week?
> >
> > Probably the latter. Which programs/libraries require it?
>
> GDAL compiled with OGDI.
In that case, it should only be an issue for the GDAL library. Delete
the libgdal binary which came with GRASS (from $GISBASE/lib) and
install one which is compatible with your system.
Given the large number of possible dependencies for GDAL, the chances
of a libgdal binary built for one system is working on another system
are low. It doesn't help that GDAL's configure script insists on
autodetecting everything; you have to explicitly provide --without-*
switches for any libraries which you don't want to use.
Probably the simplest solution is to either build GDAL yourself from
source code, or install your OS vendor's "official" GDAL package (if
they have one), along with all of the necessary dependencies (package
management tools such as RPM will either do this for you or at least
tell you what you need to install).
- --
Paolo Cavallini
cavallini@faunalia.it www.faunalia.it www.faunalia.com
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953
http://pkg-grass.alioth.debian.org/cgi-bin/wiki.pl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBougP/NedwLUzIr4RArqAAJ90iaRR9phvlGPS8JSKyKoEQ2VfZACdFb2+
2fULFaKIb139QGUws2CNzKM=
=72a8
-----END PGP SIGNATURE-----
On Mon, Nov 22, 2004 at 05:48:37PM +0100, Leonardo Lami wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
installing the new version of GRASS (20-11) I see that there is a new needed
library (libogdi31.so) that is available only for Mandrake.
Here it is:
http://ogdi.sourceforge.net/
"OGDI is the Open Geographic Datastore Interface".
It is used to import for example VMAP0 vector data.
Is it a truly needed library or only a bug in the binary of the week?
Do you refer to the 'grass.itc.it' binaries?
Since they are linked against dynamic GDAL libs I don't see the
problem (as I am not aware of distributing GDAL on 'grass.itc.it').
tar tvfz grass-5.7.cvs-i686-pc-linux-gnu-20_11_2004.tar.gz |grep -i gdal
-rwxr-xr-x neteler/grass 19520 2004-11-20 07:04:50 bin/r.in.gdal
-rw-r--r-- neteler/grass 6476 2004-11-20 07:04:51 docs/html/r.in.gdal.html
-rw-r--r-- neteler/grass 3312 2004-11-20 07:07:14 docs/html/r.out.gdal.html
-rw-r--r-- neteler/grass 78706 2004-11-20 06:57:42 etc/ogr_csv/gdal_datum.csv
-rw-r--r-- neteler/grass 2699 2004-11-20 07:09:18 man/man1/r.out.gdal.1
-rwxr-xr-x neteler/grass 3430 2004-11-20 07:07:14 scripts/r.out.gdal
Could you go into the lib/ directory of the installed binary
snapshot and run
ldd * > lib_deps.txt
and post this file to me (not to the list)?
The library seems avalaible only for Mandrake and it is aproblem for all other
linux distribution.
Here you can get linux/SUN/MS-Windows etc binaries:
http://sourceforge.net/project/showfiles.php?group_id=11181
http://rpmfind.net/linux/rpm2html/search.php?query=ogdi&submit=Search+…
etc
(ok, seems to be missing in Debian)
If you compiled GDAL yourself, simply diable OGDI:
--without-ogdi
Please let me know where you got GRASS and where you got GDAL
to better understand the problem.
Markus
On Tue, Nov 23, 2004 at 01:45:57AM +0000, Glynn Clements wrote:
Sandro Klippel wrote:
> > > installing the new version of GRASS (20-11) I see that there is a new
> > > needed library (libogdi31.so) that is available only for Mandrake.
> > > Is it a truly needed library or only a bug in the binary of the week?
> >
> > Probably the latter. Which programs/libraries require it?
>
> GDAL compiled with OGDI.
In that case, it should only be an issue for the GDAL library. Delete
the libgdal binary which came with GRASS (from $GISBASE/lib) and
install one which is compatible with your system.
If he used the 5.7 binaries from grass.itc.it there shouldn't be
any GDAL libs included. Otherwise please notify me.
Markus
Markus Neteler wrote:
Do you refer to the 'grass.itc.it' binaries?
Since they are linked against dynamic GDAL libs I don't see the
problem (as I am not aware of distributing GDAL on 'grass.itc.it').
FWIW, the 5.3 documents/release_rules.txt file still says:
o For r.in.gdal we need "libgdal" which has to be included into the GRASS
binary package. Finally store "libgdal.1.1.so" in $GISBASE/lib/
--
Glynn Clements <glynn@gclements.plus.com>
On Tue, Nov 23, 2004 at 10:30:37AM +0000, Glynn Clements wrote:
Markus Neteler wrote:
> Do you refer to the 'grass.itc.it' binaries?
> Since they are linked against dynamic GDAL libs I don't see the
> problem (as I am not aware of distributing GDAL on 'grass.itc.it').
FWIW, the 5.3 documents/release_rules.txt file still says:
o For r.in.gdal we need "libgdal" which has to be included into the GRASS
binary package. Finally store "libgdal.1.1.so" in $GISBASE/lib/
Yes, but he was refering to GRASS 5.7.
In a personal communication it turned out to be a local problem
as also netcdf, jasper etc was used which are not even installed
on grass.itc.it.
Markus
On Tue, Nov 23, 2004 at 09:53:04AM +0100, Paolo Cavallini wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ciao Markus.
Here it is.
GRASS from itc binaries (not compiled) on a Debian Sarge box, with GDAL from
Debian package.
Tried on a couple of machines, with identical results.
Thanks.
pc
At 09:34, martedì 23 novembre 2004, Markus Neteler has probably written:
> On Mon, Nov 22, 2004 at 05:48:37PM +0100, Leonardo Lami wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi,
> > installing the new version of GRASS (20-11) I see that there is a new
> > needed library (libogdi31.so) that is available only for Mandrake.
Found it.
After quite some debugging I found the problem:
The recent change in the configuration to use -deps for GDAL
introduces the "new" ogdi31 dependency:
Platform.make:GDALLIBS = -L/usr/local/lib -lgdal -lodbc -logdi31 -lgif -ljpeg -lpng -L/usr/local/lib -L/usr/local/lib/lib -lgrass5 -lz -lm -ldl -L/usr/lib -lpq
grep dep-libs ~/grass57/configure.in
GDAL_DEP_LIBS=`"$GDAL_CONFIG" --dep-libs 2>/dev/null`
The only way may be that I have to diable OGDI on 'grass.itc.it' and
reinstall it there. Also the libgrass support I'll have to remove (which
then break the GRASs/Mapserver interface...). Sigh.
Markus
Markus Neteler wrote:
Found it.
After quite some debugging I found the problem:
The recent change in the configuration to use -deps for GDAL
introduces the "new" ogdi31 dependency:
Platform.make:GDALLIBS = -L/usr/local/lib -lgdal -lodbc -logdi31 -lgif -ljpeg -lpng -L/usr/local/lib -L/usr/local/lib/lib -lgrass5 -lz -lm -ldl -L/usr/lib -lpq
grep dep-libs ~/grass57/configure.in
GDAL_DEP_LIBS=`"$GDAL_CONFIG" --dep-libs 2>/dev/null`
The only way may be that I have to diable OGDI on 'grass.itc.it' and
reinstall it there. Also the libgrass support I'll have to remove (which
then break the GRASs/Mapserver interface...). Sigh.
Markus
I have removed --deb-libs, it is probably better to have
GRASS compiled without those dependencies, even if compilation
can fail if libs are not in standard dirs.
Radim
Radim Blazek wrote:
Markus Neteler wrote:
>
> Found it.
> After quite some debugging I found the problem:
> The recent change in the configuration to use -deps for GDAL
> introduces the "new" ogdi31 dependency:
>
> Platform.make:GDALLIBS = -L/usr/local/lib -lgdal -lodbc -logdi31 -lgif -ljpeg -lpng -L/usr/local/lib -L/usr/local/lib/lib -lgrass5 -lz -lm -ldl -L/usr/lib -lpq
Aha.
I have removed --deb-libs, it is probably better to have
GRASS compiled without those dependencies, even if compilation
can fail if libs are not in standard dirs.
The reason for --dep-libs is that, without it, compilation will fail
if GDAL is a static library (or a dynamic library without dependency
information).
One possible solution would be for configure to apply a link test for
GDAL, using --dep-libs only if the check fails without it. E.g.
(untested):
ac_save_ldflags="$LDFLAGS"
LDFLAGS="$LDFLAGS $GDAL_LIBS"
AC_CHECK_FUNC(GDALOpen,,[
LDFLAGS="$LDFLAGS $GDAL_DEP_LIBS"
AC_CHECK_FUNC(GDALOpen,[GDAL_LIBS="$GDAL_LIBS $GDAL_DEP_LIBS"],[
AC_MSG_ERROR([*** Unable to locate GDAL library.])
])
])
LDFLAGS=${ac_save_ldflags}
If GDAL is a static library, you can't avoid making the r.in.gdal
executable dependent on GDAL's dependencies. In that situation, GDAL
should be built with as few dependencies as practical.
--
Glynn Clements <glynn@gclements.plus.com>
On Thu, Nov 25, 2004 at 11:32:59AM +0000, Glynn Clements wrote:
Radim Blazek wrote:
> Markus Neteler wrote:
> >
> > Found it.
> > After quite some debugging I found the problem:
> > The recent change in the configuration to use -deps for GDAL
> > introduces the "new" ogdi31 dependency:
> >
> > Platform.make:GDALLIBS = -L/usr/local/lib -lgdal -lodbc -logdi31 -lgif -ljpeg -lpng -L/usr/local/lib -L/usr/local/lib/lib -lgrass5 -lz -lm -ldl -L/usr/lib -lpq
Aha.
> I have removed --deb-libs, it is probably better to have
> GRASS compiled without those dependencies, even if compilation
> can fail if libs are not in standard dirs.
The reason for --dep-libs is that, without it, compilation will fail
if GDAL is a static library (or a dynamic library without dependency
information).
On grass.itc.it GDAL is a dynamic library.
One possible solution would be for configure to apply a link test for
GDAL, using --dep-libs only if the check fails without it. E.g.
(untested):
ac_save_ldflags="$LDFLAGS"
LDFLAGS="$LDFLAGS $GDAL_LIBS"
AC_CHECK_FUNC(GDALOpen,,[
LDFLAGS="$LDFLAGS $GDAL_DEP_LIBS"
AC_CHECK_FUNC(GDALOpen,[GDAL_LIBS="$GDAL_LIBS $GDAL_DEP_LIBS"],[
AC_MSG_ERROR([*** Unable to locate GDAL library.])
])
])
LDFLAGS=${ac_save_ldflags}
We can make a try of course.
How should this be done?
If GDAL is a static library, you can't avoid making the r.in.gdal
executable dependent on GDAL's dependencies. In that situation, GDAL
should be built with as few dependencies as practical.
OK. But in the current 'case study' we are dealing with dynamic libs.
Markus
On Wed, Nov 24, 2004 at 04:14:35PM +0100, Markus Neteler wrote:
On Tue, Nov 23, 2004 at 09:53:04AM +0100, Paolo Cavallini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ciao Markus.
> Here it is.
> GRASS from itc binaries (not compiled) on a Debian Sarge box, with GDAL from
> Debian package.
> Tried on a couple of machines, with identical results.
> Thanks.
> pc
>
> At 09:34, martedì 23 novembre 2004, Markus Neteler has probably written:
> > On Mon, Nov 22, 2004 at 05:48:37PM +0100, Leonardo Lami wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Hi,
> > > installing the new version of GRASS (20-11) I see that there is a new
> > > needed library (libogdi31.so) that is available only for Mandrake.
Found it.
After quite some debugging I found the problem:
The recent change in the configuration to use -deps for GDAL
introduces the "new" ogdi31 dependency:
Platform.make:GDALLIBS = -L/usr/local/lib -lgdal -lodbc -logdi31 -lgif -ljpeg -lpng -L/usr/local/lib -L/usr/local/lib/lib -lgrass5 -lz -lm -ldl -L/usr/lib -lpq
grep dep-libs ~/grass57/configure.in
GDAL_DEP_LIBS=`"$GDAL_CONFIG" --dep-libs 2>/dev/null`
Above GDAL_DEP_LIBS trick has been reverted,
The new shapshot should be ok now. Please try again
and complain if needed:
http://grass.itc.it/grass57/binary/linux/snapshot/
Markus
Markus Neteler wrote:
> One possible solution would be for configure to apply a link test for
> GDAL, using --dep-libs only if the check fails without it. E.g.
> (untested):
>
> ac_save_ldflags="$LDFLAGS"
> LDFLAGS="$LDFLAGS $GDAL_LIBS"
> AC_CHECK_FUNC(GDALOpen,,[
> LDFLAGS="$LDFLAGS $GDAL_DEP_LIBS"
> AC_CHECK_FUNC(GDALOpen,[GDAL_LIBS="$GDAL_LIBS $GDAL_DEP_LIBS"],[
> AC_MSG_ERROR([*** Unable to locate GDAL library.])
> ])
> ])
> LDFLAGS=${ac_save_ldflags}
We can make a try of course.
How should this be done?
I've committed the above to CVS. It appears to work for a dynamic GDAL
library (GDAL's dependencies don't get added to r.in.gdal). I haven't
tested it with a static GDAL library.
BTW, r.in.gdal still has quite a lot of dependencies, some of them
(curses, FFTW) because r.in.gdal requires some functions from the
imagery library, and the imagery library has a lot of dependencies
(for functions which r.in.gdal doesn't use).
Some of the libraries should either be refactored or built as static
libraries. The imagery library is a prime candidate, but libgis and
libgmath also have issues. libgis requires the socket library solely
for unix_socks.c, which is only used by the raster library and the
display drivers. libgmath requires FFTW solely for the FFT code.
--
Glynn Clements <glynn@gclements.plus.com>