Hi Frank,
[cc to GRASS 5]
On Wed, Mar 21, 2001 at 10:08:33AM -0500, Frank Warmerdam wrote:
Markus Neteler wrote:
> Thanks, Frank!
> Of course it will be included in the next binary package.
>
> Additionally we would need Solaris/SUN, Solaris/Intel and SGI
> versions, hopefully you can get volunteers to build that for you.
>
> The addition of this lib is documented in the release rules for
> GRASS binaries.
Markus, et al,
I have made IRIX 6.5, and Solaris 2.7 shared libaries available in the
same place.
http://gdal.velocet.ca/projects/grass/index.html
Great, this is perfect for the other binary releases of GRASS.
I would be happy to help anyone interested in building for Solaris/INTEL,
MacOS X, Cygwin, etc. Let me know if the files I have created don't work
properly.
Best regards,
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.
Regards
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
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?
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.
Best regards,
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerda
and watch the world go round - Rush | Geospatial Programmer for Rent
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
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@geog.uni-hannover.de with
subject 'unsubscribe grass5'