[STATSGRASS] GSTAT 2.4.3 compile problem with GRASS 5.4

Edzer J. Pebesma e.pebesma at geog.uu.nl
Wed Mar 16 02:36:16 EST 2005


Roger Bivand wrote:

>On Tue, 15 Mar 2005, Edzer J. Pebesma wrote:
>
>  
>
>>Roger Bivand wrote:
>>    
>>
>>>On Tue, 15 Mar 2005, Thomas Adams wrote:
>>>
>>>
>>>      
>>>
>>>>I am having GSTAT 2.4.3 compile problems with GRASS 5.4. When 
>>>>configuring gstat for compilation I use:
>>>>
>>>>./configure --with-grass=/awips/rep/lx/local_apps/grass-build
>>>>
>>>>The GRASS 5.4 lib & include directories are located in 
>>>>/awips/rep/lx/local_apps/grass-build, but I notice when gstat is being 
>>>>configured for compilation, I get:
>>>>
>>>>checking for G_gisinit in -lgrass_gis... no
>>>>checking for G_gisinit in -lgis... no
>>>>
>>>>        
>>>>
>>>Edzer: is this related to 5.4.0 going just shared? That only the *.so are 
>>>in build/dist*/lib? On grass5, Glynn asked on Sunday:
>>>
>>>"I think that the point is that binary distributions should always
>>>include the libraries regardless of whether they are shared or static. 
>>>IIRC, we currently only include the libraries if they are shared
>>>libraries.
>>>
>>>From a packaging (RPM etc) perspective, static libraries would
>>>normally go into a separate -devel package, along with the headers,
>>>while shared libraries would go into the main package."
>>>
>>>The configure seems to fail because it is looking for libgis.a or 
>>>libgrass_gis.a at:
>>>
>>> AC_CHECK_LIB(grass_gis, G_gisinit, GISLIB="-lgrass_gis -lgrass_datetime",
>>>  AC_CHECK_LIB(gis, G_gisinit, GISLIB="-lgis -ldatetime"))
>>>
>>>isn't it? Should it see a *.so as an *.a, they are different animals, 
>>>aren't they?
>>>      
>>>
>>No. They're different, but the .a are not required. gstat 2.4.4
>>links to grass-6.0.0beta1, which contains only .so in the lib dir;
>>I tried the 2.4.3 (targeted at grass 5.x) and the configure
>>worked on the grass6 machine, it finds the .so libraries. Then it
>>doesn't compile, for obvious reasons.
>>
>>Thomas, could you double-check the directory names?
>>    
>>
>
>It could be that grass-build is actually grass-build/dist.*
>
>I've tried without success with 2.4.3 on 5.4.0 on my machine, both going 
>for the grass-build/dist* and the install directory grass54/ which has lib 
>in it. I've got a working 5.4.0 (I think).
>
>  
>
Roger, I'm sorry, you were right, but it can be solved easily.

The issue is that dynamic libraries are only linked against
automatically if they are in a "trusted"
directory, which are on my machine listed in /etc/ld.so.conf
(run ldconfig after you modify it; read man ldconfig).

So if you want to run gstat with grass support any way,
you'd have to add the /usr/local/grassxxx/lib directory
there, and run ldconfig.

If you _only_ want to run gstat within grass sessions (which
makes sense, because only then it should know where to
look for data!) you should run

./configure --with-grass=/path/to/grass

within the grass shell, because grass sets the
environment variable to your active grass version lib dir:

LD_LIBRARY_PATH=/usr/local/grass-6.0.0beta1/lib

which has the same effect, but only for the session in
which this env var is set.

In that case, when gstat is ran outside a grass session
you'll get something like

gstat: error while loading shared libraries: libgrass_gis.so: cannot 
open shared object file: No such file or directory

because gstat (actually the runtime linker) doesn't know
where to find the .so files. I figure you get this too when
running grass binaries outside a grass shell.

Best regards,
--
Edzer




More information about the grass-stats mailing list