[GRASSLIST:4959] Re: libogdi31.so

[Markus Neteler]

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