[GRASS-dev] strange thing on compilation of cvs

[Glynn Clements]

Hamish wrote:

> > Yann Chemin wrote:
> > 
> > > I am moving to a Debian based distro (Kanotix: Debian unstable/sid).
> > > did a fresh cvs update, in configure, i did not enable MySQL.
> > > 
> > > while installing, many (all?) vector modules failed, including
> > > /lib/proj, the first one to fail on the list. While doing "make" in
> > > /lib/proj, i discovered that it was requiring libmysqlclient... after
> > > an apt-get install libmysqlclient15-dev, it is fixed.
> > > 
> > > is it a new requirement? or something i did wrong?
> 
> Glynn Clements wrote:
> > lib/proj uses GDAL, so it requires whatever GDAL requires. If GDAL
> > requires MySQL, then so does anything which uses GDAL.
> > 
> > If GDAL requires the MySQL client library, but you managed to install
> > the GDAL -dev package without installing the MySQL client -dev
> > package, that suggests that the GDAL -dev package doesn't have correct
> > dependency information.
> > 
> > The problem could lie elsewhere, but I'm fairly sure that it lies
> > outside of GRASS. If you don't use --with-mysql, there won't be any
> > references to libmysqlclient in any of the Makefiles, so the only way
> > it can be referenced is as a dependency of an external library.
> > 
> > And that library is probably GDAL, due to the number of optional
> > dependencies (one of which is MySQL).
> 
> 
> Now we have a third report of the same problem with 6.3-cvs.
> 
> Solution: install the libgeos-dev package to get usr/lib/libgeos.so.
> 
> 
> My guess is that recent grass63/lib/proj/ changes now call a new libproj
> or gdal fn which uses GEOS calls.. No idea what change in GRASS63 it was,
> just that it happened in the first two weeks of november. (my gdal
> install hasn't been changed in many months and worked for many grass
> compiles in that time)

PROJ doesn't use GEOS, but GDAL does.

If GDAL is a shared library, then anything which uses GDAL needs all
of its dependencies, regardless of exactly *which* GDAL functions it
calls.

Furthermore, even if GDAL is a static library,
"gdal-config --dep-libs" gives you all of the dependencies, not just
the ones which are needed for the specific object files which are
being used.

Trying to determine the dependencies for individual functions isn't
feasible, IMHO. Even if it was, I'm not sure that it would make much
difference for GDAL, as the "top-level" functions (e.g. GDALOpen())
will eventually reference most of the dependencies.

The fact that they only get used for specific data formats doesn't
affect anything; if GDAL was built with e.g. JPEG2000 support, you
will need the JPEG2000 library at link time, regardless of whether or
not you subsequently read any JPEG2000 files.

> I think the real bug is that Debian's libgdal-dev needs to depend on the
> libgeos-dev package.
> 
> sarge$ apt-cache show libgdal1-1.3.1-dev
> Version: 1.3.1-0.dgis.stable.2
> Depends: libgdal1-1.3.1 (= 1.3.1-0.dgis.stable.2), libc6-dev, libcfitsio-dev, netcdfg-dev, libtiff4-dev, libjasper-1.701-dev, libpng12-dev, libjpeg62-dev, libungif4-dev, libhdf4g-dev, libpq-dev | postgresql-dev, libxerces26-dev, unixodbc-dev, libsqlite0-dev

And presumably the -dev package for MySQL (or at least the client
library) as well.

The only issue specifically related to GRASS is that configure.in
doesn't actually perform a link test for GDAL. It just runs
gdal-config and sets the appropriate variables. If GDAL isn't usable,
you won't actually find out until you run "make".

We should probably add something like:

	ac_save_libs="$LIBS"
	LIBS="$GDAL_LIBS $LIBS"
	AC_CHECK_FUNC(GDALOpen,,[AC_MSG_ERROR([*** Unable to use GDAL library.])])
	LIBS=$ac_save_libs

to the GDAL section of configure.in.

-- 
Glynn Clements <glynn at gclements.plus.com>