Solaris and XGRASS 4.2.1

[Clifton Wood]

Hey folks!

I was trying to get XGRASS v4.2.1. running on my Solaris v2.6 box when I
ran into a few problems...first, I noticed that XGrass was making a call
to "/lib/cpp" which doesn't exist on my system and afterward, quickly
crashed with a core dump. I corrected this (changed it to
/usr/ccs/lib/cpp) and rebuilt the executables and tried again, only to
get the same core dump, gdb reports the program stack as:

(gdb) backtrace
#0  0xef634170 in _XmManagerInstallMnemonic (m=0x85958, w=0x9fea8,
mn=70)
    at Manager.c:1967
#1  0xef612ff8 in initialize (request=0xefffd898, new_w=0x9fea8, 
    args=0xefffd7c0, num_args=0xefffd74c) at Label.c:716
#2  0xef5268f4 in CallInitialize ()
#3  0xef526898 in CallInitialize ()
#4  0xef526f58 in xtCreate ()
#5  0xef5274c4 in _XtCreateWidget ()
#6  0xef559af4 in _XtVaCreateWidget ()
#7  0xef559ca8 in XtVaCreateManagedWidget ()
#8  0x1bfa8 in __XgHistorySetup ()
#9  0x1a3c0 in main ()

I was curious if there is a relation between the coredump, the call to
"cpp" and one of the above routines. I'll be peeking in the code to see
if I can get an inkling as to what's going wrong on this end, but XGRASS
is a huge and
daunting program, even with the source available.

So before I start examining every line with a fine tooth comb...has
anyone gotten XGrass to work on a Sun UltraSPARC running Solaris v2.6?
That way at least I'll have some inkling as to how serious the problem
is.

Thanks.

-- 
============================================================
Clifton B. Wood
Programmer/Analyst for Virginia Tech's AGNIS Department
-------------------- Thought of the Day --------------------
windows95 = n.  32 bit extensions and a graphical shell for
a 16 bit patch to an 8 bit operating system originally coded
for a 4 bit microprocessor, written by a 2 bit company that 
can't stand 1 bit of competition.