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

[Markus Neteler]

On Wed, Mar 01, 2006 at 05:34:22PM +0000, Glynn Clements wrote:
> 
> 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/Pol!
 yl!
>  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.

I didn't use that.
 
> 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.

This helps.

 
> > 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.

Right, this indicates that I have circular dependencies which
could not be resolved due to the changes in libgrass_driver.
Above order modification is a way out.

> 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.

The problem is that I need them there to keep the grass-gdal plugin
running for Mapserver/GRASS-PHP.

But the LDFLAGS change should to the job, right? 
I have applied it to CVS and launched the cron job to
create the binary snaphot (should be ready in 1h from now
if it completes now).

Markus