[GRASS5] v.out.ascii: Segmentation fault

Hamish hamish_nospam at yahoo.com
Tue Nov 30 23:32:38 EST 2004

> > Now I see: It's the "famous" mysterious (to me) Debian problem:
> > 
> > For some unknown reasons Debian users have to add to
> > /etc/ld.so.conf
> > 
> > the directory of the GRASS libs, here:
> > /usr/local/grass-5.7.cvs/lib
> > 
> > and run
> > ldconfig
> > 
> > I would like to know that solved but have no idea why Debian behaves
> > like this (reported earlier by other Debian/GRASS users).

As Glynn pointed out a few weeks ago, as a security precaution Debian's
xterm does not export $LD_LIBRARY_PATH to child processes.

> > It's probably related to the fact that Debian searches in
> >  /usr/local/grass-5.7.cvs/lib/tls/i686/mmx/
> >                               ^^^^^^^^^^^^^
> > Why this?
> With recent versions of glibc, the loader searches for
> architecture-specific libraries first. I've seen the same behaviour on
> SuSE 9.1.
> Anyhow, the problem isn't that it's searching extra directories, but
> that it doesn't appear to be searching $LD_LIBRARY_PATH.

My 5.7 is a couple of weeks old now, but everything works fine for me on
Debian/testing. I don't use d.m much, might be problems there.

I use tcl/tk 8.3.

Also I suspect a lot of these problems come from people using the
grass.itc.it linux (but not debian) binaries and then libraries not
being where the binaries expect them to be.

Only problem I get is d.what.vect in form mode rarely exiting on the
first click (without an error). Haven't been able to reproduce this with
the debugger running. Next time I see it I'll do "echo $?" at least.
Never had the "works once" d.what.vect problem.

Same for me on about 5 different debian computers.. no problems.


More information about the grass-dev mailing list