[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