[GRASSLIST:4958] Re: libogdi31.so

Glynn Clements glynn at gclements.plus.com
Thu Nov 25 06:32:59 EST 2004


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 at gclements.plus.com>




More information about the grass-user mailing list