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