Installing Grass for Solaris

[Grass package]

Hi Ken,
thanks for your prompt reply. I'll try to annotate your points in order
to narrow down the problem:
> 
> Common problems with display locking:
> 1)  When on machines not running X (mostly SCS sites) you will not
>     have the display directory level.  Can cause problems for custom
>     interfaces that expect specific paths.
I'm running grass displays under Windows Exceed, so I suppose as far as
Grass is concerned that's just X. The translations to local graphics are
not seen by grass. Having said that, I do not have a display directory level, just lock files called mon.36585 mon.36586 with no readable information in them.

> 2)  If you do not have write permission to the locks directory you 
>     cannot lock the display.  You will get an error message.
No problems here.

> 3)  The first time you start a display in grass you will get an error
>     message saying cannot complete locking process even when everything
>     seems correct.  The reason is that the directories and the file
>     are not able to be created in the same openf() call.  Therefore
>     the directory(ies) is(are) created the first time you start the
>     monitor.  If you immediately stop the monitor and then restart the
>     monitor it will work fine.  This will happen any time a new machine
>     or new display is used to start a monitor as the appropriate directory
>     is created.
Again, nothing wrong here.

> 4)  If grass is terminated unnaturely the display lock file can be left
>     in the locks/* directory by accident.  Check and see if the process
>     is still running.  If it is then kill it.  Then remove the lock file.
>     You should then be able to start the monitor with no problem.  If 
>     the system crashes the process will not be running, but you probably
>     will still have to remove the lock file ($GISBASE/locks/*).
This happens all the time. I have killed the processes and removed the lock
files but the monitors still won't run. Also, I get the `already running'
message which means that somehow grass remembers about these monitors. The
monitor.status command hangs.

> 5)  The only thing left are the fifos.  The fifos must exist in the
>     path designated in the $GISBASE/etc/monitorcap file.  This is usually
>     in the $GISBASE/dev directory.  Permissions should be 666.
>     Sometimes the fifos are accidently overwritten such that 
>     they become files rather than character devices
>     as they should be.  This also happens if someone backs GRASS up to a 
>     tape and reloads or copies the software to a new location.  In this
>     case remove the fifo files and recreate using the mknod command.
>     NOTE: The file may still have permissions crw-rw-rw- and still need
>     to be recreated.  cpio will leave the file looking like this.
Now this is interesting. My fifo were indeed normal files, not named pipes
like they should be, but I thought this was caused by the incorporation
of the `message queue' system in the solaris binaries. So I created a new
monitor and fifo pipe to test this, and I did manage to start it but then
the d.mon program hung and I had to Ctrl-C it. Wait a minute, did you say
`character device'?? I haven't tried that yet. Will let you know later on
if that makes any difference...

> 
> Sorry for the long windedness, but there are so many little details,
> Ken Sibley
Oh no, please, I'm grateful that you take the time to help me with this.
To tell you the truth, I think I'm going to try and compile grass from 
source because I'm getting fed up with these binaries...

Thanks again for yuor help so far,

Martijn van Leusen

> USDA-SCS/NCG		"Hell, if you understand everything I say,
> ksibley at ncg.scs.ag.gov   you'd be me!"  - Miles Davis
> 
>