[GRASSLIST:10658] Re: problems with GIS manager Re: GRASS 6.1cvs gis.m error

Glynn Clements glynn at gclements.plus.com
Wed Mar 1 12:34:22 EST 2006


Markus Neteler wrote:

> > > > > A similar message is produced for every other monitor. I also noticed that
> > > > > in the Feb.25th Grass 6.1 binary, there is no monitorcap file in
> > > > > $GISBASE/etc. I believe there used to a be a monitorcap file here a few
> > > > > weeks ago, because I remember having to remove/overwrite it with the one
> > > > > from the gis.m tarfile. Is this normal?
> > > > 
> > > > No. Do either driver/PNG or driver/XDRIVER exist?
> > > 
> > > Aha. No, driver/PNG and driver/XDRIVER don't exist. So somehow support for
> > > these drivers was excluded recently from the generic linux binaries? Is it a
> > > simple task to get support built back in?
> > 
> > I would guess that compilation simply failed for some reason. I don't
> > know if the build process for the snapshots keeps logs which would
> > indicate why, or if that even matters now.
> 
> Amusingly, I am currently working on this in grass.itc.it :-)
>  
> > Obviously, if the problem recurs, that indicates an outstanding bug
> > which needs to be fixed. Right now, it's probably more important to
> > figure out what to do if we end up with a weekly snapshot which is
> > substantially broken (like the Feb 25 one).
> 
> So:
> 
> cat error.log
> GRASS GIS compilation log
> -------------------------
> Started compilation: Tue Feb 28 23:35:01 CET 2006
> --
> Errors in:
> /hardmnt/grass0/neteler/grass61_cvs_pserver/grass6/display/drivers/PNG
> /hardmnt/grass0/neteler/grass61_cvs_pserver/grass6/display/drivers/XDRIVER
> 
> That's why monitorcap is missing.

And if it was present, it wouldn't be much use.

> > As it stands, the choice is between 6.0.2, a snapshot which is
> > essentially useless, waiting nearly a week for the next snapshot, or
> > learning to build GRASS from source (non-trivial, given the number of
> > dependencies).
> 
> Why not simply bothering the maintainer of grass.itc.it (still a
> Redhat 7.3 box)?
> 
> Here we are:
> 
> bash-2.04$ cd display/drivers/XDRIVER
> bash-2.04$ make
> gcc -Wl,--export-dynamic  -L/usr/local/lib -L/hardmnt/grass0/neteler/grass61_cvs_pserver/grass6/dist.i686-pc-linux-gnu/lib -Wl,-rpath-link,/hardmnt/grass0/neteler/grass61_cvs_pserver/grass6/dist.i686-pc-linux-gnu/lib   -o /hardmnt/grass0/neteler/grass61_cvs_pserver/grass6/dist.i686-pc-linux-gnu/driver/XDRIVER  -L/hardmnt/grass0/neteler/grass61_cvs_pserver/grass6/dist.i686-pc-linux-gnu/lib OBJ.i686-pc-linux-gnu/Box.o OBJ.i686-pc-linux-gnu/Can_do.o OBJ.i686-pc-linux-gnu/Client.o OBJ.i686-pc-linux-gnu/Color_table.o OBJ.i686-pc-linux-gnu/Color.o OBJ.i686-pc-linux-gnu/Draw_bitmap.o OBJ.i686-pc-linux-gnu/Draw_line.o OBJ.i686-pc-linux-gnu/Draw_point.o OBJ.i686-pc-linux-gnu/Get_w_box.o OBJ.i686-pc-linux-gnu/Get_w_line.o OBJ.i686-pc-linux-gnu/Get_w_pointer.o OBJ.i686-pc-linux-gnu/Graph_close.o OBJ.i686-pc-linux-gnu/Graph_set.o OBJ.i686-pc-linux-gnu/Line_width.o OBJ.i686-pc-linux-gnu/Panel.o OBJ.i686-pc-linux-gnu/Polydots.o OBJ.i686-pc-linux-gnu/Polygon.o OBJ.i686-pc-linux-gnu/Polyl!
 in!
>  e.o OBJ.i686-pc-linux-gnu/Raster.o OBJ.i686-pc-linux-gnu/Raster_RGB.o OBJ.i686-pc-linux-gnu/Respond.o OBJ.i686-pc-linux-gnu/Serve_Xevent.o OBJ.i686-pc-linux-gnu/Work.o OBJ.i686-pc-linux-gnu/alloc.o OBJ.i686-pc-linux-gnu/main.o -lgrass_driver -lgrass_gis -lgrass_datetime -lz    -lfreetype   -L/usr/X11R6/lib -lSM -lICE -lX11  -lm  -lz
> /usr/local/lib/libgrass_driver.a(main.o): In function `main':

It's using the version in /usr/local/lib rather than in the build
tree. That's because -L/usr/local/lib comes first. Doesn't the linker
look there automatically? If it doesn't, don't use
--with-libs=/usr/local/lib when configuring.

In any case, the definition of LDFLAGS in Grass.make.in should
probably be changed from:

	LDFLAGS     =  $(LINK_FLAGS) $(LIBPATH) $(LD_SEARCH_FLAGS) $(PQLIBPATH) $(USE_TERMIO)

to:

	LDFLAGS     =  $(LIBPATH) $(LINK_FLAGS) $(LD_SEARCH_FLAGS) $(PQLIBPATH) $(USE_TERMIO)

so that the GRASS build tree is searched before system directories.

> main.o(.text+0x40): multiple definition of `main'
> OBJ.i686-pc-linux-gnu/main.o:/hardmnt/grass0/neteler/grass61_cvs_pserver/grass6/display/drivers/XDRIVER/main.c:6: first defined here


> /usr/bin/ld: Warning: size of symbol `main' changed from 301 to 956 in main.o
> OBJ.i686-pc-linux-gnu/Color_table.o: In function `init_color_table':
> /hardmnt/grass0/neteler/grass61_cvs_pserver/grass6/display/drivers/XDRIVER/Color_table.c:302: undefined reference to `DRV_lookup_color'
> /hardmnt/grass0/neteler/grass61_cvs_pserver/grass6/display/drivers/XDRIVER/Color_table.c:302: undefined reference to `LIB_assign_standard_color'

These are all symptoms of using the wrong version of libgrass_driver.

If possible, remove the GRASS libraries from /usr/local/lib (similarly
for include, bin etc). Having them there could mask problems with the
build. If a library fails to build, anything which depends upon it
should fail to build, rather than using an installed version of the
library.

-- 
Glynn Clements <glynn at gclements.plus.com>




More information about the grass-user mailing list