The new v.voronoi fails to build,
"libgrasss_raster.so not found, needed by libgrass_display.so"
libgrass_display.so: undefined reference to `R_pad_delete'
etc.
Hamish
Hamish wrote:
The new v.voronoi fails to build,
"libgrasss_raster.so not found, needed by libgrass_display.so"
libgrass_display.so: undefined reference to `R_pad_delete'
The v.voronoi Makefile needs to be changed to mention the raster
library:
LIBES = $(VECTLIB) $(DISPLAYLIB) $(RASTERLIB) $(GISLIB)
DEPENDENCIES= $(VECTDEP) $(DISPLAYDEP) $(RASTERDEP) $(GISDEP)
Although it would be preferable to change Grass.make.in so that each
*LIB variable includes all of the necessary dependent libraries. Then,
the Makefiles would only reference the libraries which they use
directly. This is already the case for GISLIB, GMATHLIB and GPROJLIB.
--
Glynn Clements <glynn.clements@virgin.net>
On Thu, Oct 14, 2004 at 05:49:57PM +1300, Hamish wrote:
The new v.voronoi fails to build,
"libgrasss_raster.so not found, needed by libgrass_display.so"
libgrass_display.so: undefined reference to `R_pad_delete'
On RH7/RH9/MDK10 no problem. Which OS/platform are you refering to?
v.voronoi ismaa_centraline out=voronoi
Building topology ...
49 areas built %
1 isles built
Topology was built.
Number of nodes : 151
Number of primitives: 201
Number of points : 0
Number of lines : 0
Number of boundaries: 150
Number of centroids : 51
Number of areas : 49
Number of isles : 1
Number of incorrect boundaries : 2
Number of duplicate centroids : 2
^^^^^^ bug or feature?
Probably some input points are directly on the border?
Markus
Markus Neteler wrote:
> The new v.voronoi fails to build,
>
>
> "libgrasss_raster.so not found, needed by libgrass_display.so"
>
> libgrass_display.so: undefined reference to `R_pad_delete'On RH7/RH9/MDK10 no problem. Which OS/platform are you refering to?
AFAICT, the error will occur if the shared libraries aren't in a
directory where the loader would normally find them.
The link command for shared libraries on Linux (possibly other
platforms) should include:
-Wl,-rpath-link,$(ARCH_LIBDIR)
This will tell the linker to look in $(ARCH_LIBDIR) for shared
libraries which aren't explicitly linked via a -l switch but are
dependencies of other shared libraries.
--
Glynn Clements <glynn.clements@virgin.net>
On Thu, 14 Oct 2004 13:24:29 +0200
Markus Neteler <neteler@itc.it> wrote:
On Thu, Oct 14, 2004 at 05:49:57PM +1300, Hamish wrote:
> The new v.voronoi fails to build,
>
>
> "libgrasss_raster.so not found, needed by libgrass_display.so"
>
> libgrass_display.so: undefined reference to `R_pad_delete'On RH7/RH9/MDK10 no problem. Which OS/platform are you refering to?
Debian/testing on i686.
Hamish
> The new v.voronoi fails to build,
>
> "libgrasss_raster.so not found, needed by libgrass_display.so"
>
> libgrass_display.so: undefined reference to `R_pad_delete'The v.voronoi Makefile needs to be changed to mention the raster
library:LIBES = $(VECTLIB) $(DISPLAYLIB) $(RASTERLIB) $(GISLIB)
DEPENDENCIES= $(VECTDEP) $(DISPLAYDEP) $(RASTERDEP) $(GISDEP)
This works, committed.
Hamish
On Thu, Oct 14, 2004 at 01:13:28PM +0100, Glynn Clements wrote:
Markus Neteler wrote:
> > The new v.voronoi fails to build,
> >
> >
> > "libgrasss_raster.so not found, needed by libgrass_display.so"
> >
> > libgrass_display.so: undefined reference to `R_pad_delete'
>
> On RH7/RH9/MDK10 no problem. Which OS/platform are you refering to?AFAICT, the error will occur if the shared libraries aren't in a
directory where the loader would normally find them.
You are right. I forgot that I linked the libgrass* into
/usr/local/lib for QGIS convenience (yes, one could also write
a startup script for QGIS and extend the LD_LIBRARY_PATH).
The link command for shared libraries on Linux (possibly other
platforms) should include:-Wl,-rpath-link,$(ARCH_LIBDIR)
This will tell the linker to look in $(ARCH_LIBDIR) for shared
libraries which aren't explicitly linked via a -l switch but are
dependencies of other shared libraries.
Should this go into aclocal.m4?
There is something like this for Linux:
747 Linux*)
748 SHLIB_CFLAGS="-fPIC"
749 SHLIB_LD_LIBS='${LIBS}'
750 SHLIB_SUFFIX=".so"
751
752 CFLAGS_OPTIMIZE=-O2
753 # egcs-2.91.66 on Redhat Linux 6.0 generates lots of warnings
754 # when you inline the string and math operations. Turn this off to
755 # get rid of the warnings.
756 #CFLAGS_OPTIMIZE="${CFLAGS_OPTIMIZE} -D__NO_STRING_INLINES -D__NO_MATH_INLINES"
757
758 if test "$have_dl" = yes; then
759 SHLIB_LD="${CC} -shared"
760 LDFLAGS="-Wl,--export-dynamic"
761 CC_SEARCH_FLAGS='-Wl,-rpath-link,${LIB_RUNTIME_DIR}'
762 LD_SEARCH_FLAGS=${CC_SEARCH_FLAGS}
763 else
764 AC_CHECK_HEADER(dld.h, [
765 SHLIB_LD="ld -shared"
766 LDFLAGS=""
767 CC_SEARCH_FLAGS=""
768 LD_SEARCH_FLAGS=""])
769 fi
Markus
Markus Neteler wrote:
> The link command for shared libraries on Linux (possibly other
> platforms) should include:
>
> -Wl,-rpath-link,$(ARCH_LIBDIR)
>
> This will tell the linker to look in $(ARCH_LIBDIR) for shared
> libraries which aren't explicitly linked via a -l switch but are
> dependencies of other shared libraries.Should this go into aclocal.m4?
Probably.
There is something like this for Linux:
759 SHLIB_LD="${CC} -shared"
760 LDFLAGS="-Wl,--export-dynamic"
761 CC_SEARCH_FLAGS='-Wl,-rpath-link,${LIB_RUNTIME_DIR}'
762 LD_SEARCH_FLAGS=${CC_SEARCH_FLAGS}
The build system ignores {LD,CC}_SEARCH_FLAGS. They are set in
Platform.make, but nothing references them. Shlib.make references
SHLIB_LDFLAGS, but nothing sets that.
According to the documentation for SC_CONFIG_CFLAGS in aclocal.m4:
# LDFLAGS - Flags to pass to the compiler when linking object
# files into an executable application binary such
# as tclsh.
# LD_SEARCH_FLAGS-Flags to pass to ld, such as "-R /usr/local/tcl/lib",
# that tell the run-time dynamic linker where to look
# for shared libraries such as libtcl.so. Depends on
# the variable LIB_RUNTIME_DIR in the Makefile. Could
# be the same as CC_SEARCH_FLAGS if ${CC} is used to link.
--
Glynn Clements <glynn.clements@virgin.net>
On Thursday 14 October 2004 13:24, Markus Neteler wrote:
On Thu, Oct 14, 2004 at 05:49:57PM +1300, Hamish wrote:
> The new v.voronoi fails to build,
>
>
> "libgrasss_raster.so not found, needed by libgrass_display.so"
>
> libgrass_display.so: undefined reference to `R_pad_delete'On RH7/RH9/MDK10 no problem. Which OS/platform are you refering to?
v.voronoi ismaa_centraline out=voronoi
Number of incorrect boundaries : 2Probably some input points are directly on the border?
It was writing a zero length boundary. Instead of finding where
it comes from, I just added a check for zero length.
Radim