BUG IN DYNAMIC LINKER ld.so: dl-version.c (was: Re: [GRASS5] Re: [GRASSLIST:1658] Re: r.in.gdal - new libgdal.1.1.so)

Markus Neteler neteler at geog.uni-hannover.de
Wed Mar 21 11:40:30 EST 2001


On Wed, Mar 21, 2001 at 10:28:01AM -0500, Frank Warmerdam wrote:
> Markus Neteler wrote:
> > Frank, there might be a related problem due to the
> >  libstdc++-libc6.2-2.so.3
> > stored in
> > $GISBASE/lib
> > for libgdal.
> > 
> > Several people have reported this error:
> >     BUG IN DYNAMIC LINKER ld.so: dl-version.c: 210: _dl_check_map_versions:
> >     Assertion 'needed != ((void *)0)' failed!
> > 
> > for nviz and r3.showdspf. I am not sure about this bug, but can it be
> > caused by the LD_LIBRARY_PATH? Probably nviz catches the wrong libstdc?
> > 
> > There seems to be a time coincidence with us adding the LD_LIBRARY_PATH into
> > $GISBASE/etc/Init.sh and above bug.
> 
> Markus, 
> 
> Does this problem go away if the libstdc .so is removed from $GISBASE/lib?
> Are nvis, and r3.showdspf C++ programs?  
I have just suggested this to those users (I can't reproduce the bug here).
Let's wait for their answers.

On my machine I have (Suse Linux 7.0):

locate libstdc
/usr/lib/gcc-lib/i486-suse-linux/2.95.2/libstdc++.a
/usr/lib/gcc-lib/i486-suse-linux/2.95.2/libstdc++.so
/usr/lib/libstdc++-3-libc6.1-2-2.10.0.a
/usr/lib/libstdc++-3-libc6.1-2-2.10.0.so
/usr/lib/libstdc++-libc6.1-1.so.2
/usr/lib/libstdc++-libc6.1-2.a.3 
/usr/lib/libstdc++-libc6.1-2.so.3
/usr/lib/libstdc++-libc6.2-2.so.3
/usr/lib/libstdc++.so.2.7.2
/usr/lib/libstdc++.so.2.8  
/usr/lib/libstdc++.so.2.9
/usr/local/grass5/lib/libstdc++-libc6.2-2.so.3 

> The c++ library is only required within $GISBASE/lib if it isn't available
> on the system.  I thought it would be pretty harmless to include under the
> assumption it should be essentially the same as system provided copies, but
> I could be wrong.  Perhaps we should "hide" the c++ shared library and only
> have users rename it to the real name if it turns out they need it. 
Could this be done on install time using "ldd" or something else on
r.in.gdal? BTW: It's suprising that the version number is coded and no
libstdc++.so -> libstdc++.so.2.9
or whatever link exists - at least for me this unusual, but obviously common
for libstdc++

Regards
 
  Markus

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'



More information about the grass-dev mailing list