[GRASS-user] Problem with GRASS 6.3 startup

GRASS GRASS user
,
1

List,

Actually this is not a new problem per se; it seems every time I build a new version of GRASS from source the Tcl/Tk GUI
fails to come up when I hit 'Enter' after selecting the Location, Mapset, etc. What happens is that the GUI trys to come-up,
flashes, and I get an error in the Term window that references a .tcl file at the last line of the start-up script.

My inelegant way of handling this in the past was to simply copy shared libraries for gdal, Tcl/Tk, and proj4 into the GRASS
lib directory. I would like to do this in a better way; what should I do? Unfortunately, I have to build *everything* in a non-
standard location due to system constraints.

What makes my current situation more difficult is that I am in another office (Salt Lake City, Utah), trying to help them get
going with GRASS and my 'fix' is not working. What we ended up doing was to secure copy my Tcl/Tk shared libs from my
machine in Ohio to the one we're installing on, and it's not working.

Supposedly, the systems I'm working on have Tcl/Tk installed, but we could not find the shared libs. Should we build Tcl/Tk
locally to ensure compatability? Is this the likely problem?

Thanks,
Tom

2

Perhaps I did not catch your actual problem, but did you have a look
here ?
http://grass.itc.it/pipermail/grassuser/2007-August/040757.html

I had the same kind of pb when I compiled gdal from sources.

Le lundi 13 août 2007 à 20:11 -0400, Thomas.Adams@noaa.gov a écrit :

List,

Actually this is not a new problem per se; it seems every time I build a new version of GRASS from source the Tcl/Tk GUI
fails to come up when I hit 'Enter' after selecting the Location, Mapset, etc. What happens is that the GUI trys to come-up,
flashes, and I get an error in the Term window that references a .tcl file at the last line of the start-up script.

My inelegant way of handling this in the past was to simply copy shared libraries for gdal, Tcl/Tk, and proj4 into the GRASS
lib directory. I would like to do this in a better way; what should I do? Unfortunately, I have to build *everything* in a non-
standard location due to system constraints.

What makes my current situation more difficult is that I am in another office (Salt Lake City, Utah), trying to help them get
going with GRASS and my 'fix' is not working. What we ended up doing was to secure copy my Tcl/Tk shared libs from my
machine in Ohio to the one we're installing on, and it's not working.

Supposedly, the systems I'm working on have Tcl/Tk installed, but we could not find the shared libs. Should we build Tcl/Tk
locally to ensure compatability? Is this the likely problem?

Thanks,
Tom

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

3

This may be the answer for you. Another thing might be that you need to
specify where the includes are with your configure script. Add parameters
like with-tcltk-includes=<path to tcltk includes>

Michael

On 8/14/07 2:29 AM, "Vincent BAIN" <bain@toraval.fr> wrote:

Perhaps I did not catch your actual problem, but did you have a look
here ?
http://grass.itc.it/pipermail/grassuser/2007-August/040757.html

I had the same kind of pb when I compiled gdal from sources.

Le lundi 13 août 2007 à 20:11 -0400, Thomas.Adams@noaa.gov a écrit :

List,

Actually this is not a new problem per se; it seems every time I build a new
version of GRASS from source the Tcl/Tk GUI
fails to come up when I hit 'Enter' after selecting the Location, Mapset,
etc. What happens is that the GUI trys to come-up,
flashes, and I get an error in the Term window that references a .tcl file at
the last line of the start-up script.

My inelegant way of handling this in the past was to simply copy shared
libraries for gdal, Tcl/Tk, and proj4 into the GRASS
lib directory. I would like to do this in a better way; what should I do?
Unfortunately, I have to build *everything* in a non-
standard location due to system constraints.

What makes my current situation more difficult is that I am in another office
(Salt Lake City, Utah), trying to help them get
going with GRASS and my 'fix' is not working. What we ended up doing was to
secure copy my Tcl/Tk shared libs from my
machine in Ohio to the one we're installing on, and it's not working.

Supposedly, the systems I'm working on have Tcl/Tk installed, but we could
not find the shared libs. Should we build Tcl/Tk
locally to ensure compatability? Is this the likely problem?

Thanks,
Tom

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

4

Thomas.Adams@noaa.gov wrote:

Actually this is not a new problem per se; it seems every time I
build a new version of GRASS from source the Tcl/Tk GUI fails to
come up when I hit 'Enter' after selecting the Location, Mapset,
etc. What happens is that the GUI trys to come-up, flashes, and I
get an error in the Term window that references a .tcl file at the
last line of the start-up script.

My inelegant way of handling this in the past was to simply copy
shared libraries for gdal, Tcl/Tk, and proj4 into the GRASS lib
directory. I would like to do this in a better way; what should I
do? Unfortunately, I have to build *everything* in a non- standard
location due to system constraints.

If you have the necessary permissions, add the directory containing
the additional libraries to /etc/ld.so.conf, then run ldconfig.
Otherwise, set LD_LIBRARY_PATH (from e.g. ~/.bashrc) to include the
directory.

What makes my current situation more difficult is that I am in
another office (Salt Lake City, Utah), trying to help them get going
with GRASS and my 'fix' is not working. What we ended up doing was
to secure copy my Tcl/Tk shared libs from my machine in Ohio to the
one we're installing on, and it's not working.

Supposedly, the systems I'm working on have Tcl/Tk installed, but we
could not find the shared libs. Should we build Tcl/Tk locally to
ensure compatability? Is this the likely problem?

Are the Tcl/Tk libraries shared or static? Also sometimes the version
number is included in the filename, e.g. libtcl8.4.so.

Note that GRASS uses Tcl/Tk in two ways: scripts (e.g. gis.m) which
use "wish", and hybrid C+Tcl/Tk programs (e.g. v.digit, NVIZ) which
use the Tcl/Tk libraries.

For gis.m to work, you need a working "wish" program. This too
sometimes includes the version number, e.g. "wish8.4"; in that case,
you need to set the environment variable GRASS_WISH to the name of the
wish program.

Hybrid programs such as v.digit and NVIZ need to link against the
Tcl/Tk libraries. This means that they may need to be built on a
similar system to the one on which they are installed, i.e. when
installing binaries compiled on a different system, NVIZ is more
likely than other GRASS modules to fail to work.

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