[GRASSLIST:4631] GRASS 5.0.0 on OS X Jaguar (10.2.1)

[Scott W Mitchell]

I'm in a similar situation to Michael O'Dell (see bottom of this mail, 
or
GRASSLIST:4616 and 4818).  However, I am on the newer version of the
Mac OS, "Jaguar" (os 10.2.1), and BEFORE the OS update I had no
troubles compiling previous versions of grass (5.0.0preX) from source.
So I started searching the mailing list archives, both for GRASS and
the "fink" system that I and many others use to manage many of the
peripheral packages used by GRASS (fink required a major update itself 
to be compatible with the newer OS).

Initially, I thought that my troubles were related to the same issues
that other fink packages went through in the 10.1.5 -> 10.2 OS update,
so I asked for help on the fink-users mailing list a couple of days
ago.  I have received only one reply, saying the author had succeeded
in compiling, but I haven't figured out a difference between his system
and mine.  It's still possible that the state of my fink-managed
libraries is an issue, or that help may come from that source, but I'm
less sure I know what's up (at that time I was sure it was a curses
issue, now I'm more confused), and Mr. O'Dell's situation suggests that
it may not be just an OS version question.

So - I'm looking for help here - first, another request for "success
stories", and also for suggestions on how best to track down the
problem.  I'd like to figure this out and share the conclusions - I
have more unix and programming experience than the average Apple user -
have been looking after unix boxes and GRASS installations for at least
a decade, but need some pointers when it comes to figuring out library
linking troubles etc.  The only other reason I didn't "pipe up"
immediately after Glynn Clement's related comment on this list (that we
need more help on the OS X front), is that I'm working hard on
finishing my Ph.D. dissertation right now and that has to be my first
priority.  Therefore my "real work" keeps going on linux boxes here,
and when I get a few minutes for a break I can look at the OS X
situation.  This will not change until at least the end of the month.
OK, now I'm really rambling, back on topic:

I am in the same boat as Michael O'Dell, in that I can't run grass
because src/general/init fails to compile.  Delving into it further, it
seems that this is because of a missing symbol E_edit_cellhd, and
following the thread back further it seems that libgeo.a never
successfully compiled (also missing symbols, _ax, _ay, ...).  I know
that's not a full story - but I have a question first.  I have been
tracking this down by going to individual directories (based on what
failed in error.log) in the source tree and using gmake5 to see what
fails.  This is a habit leftover from GISGEN/grass4 days when there was
no configure and make involved.  Is this still a good troubleshooting
method ?  Perhaps I should start the compile over the "official" way
(run make in the top directory), and capture all the output ?  Is there
a difference ?

And again, since I got so little feedback from the fink list, are there
any users out there who have successfully compiled grass5 under os 10.2
?  If so, please get in touch, I'd like to compare our situations.

Thanks very much,

Scott Mitchell
smitch at geog.utoronto.ca or smitch AT mac.com


On Wednesday, October 2, 2002, at 04:08 AM, Glynn Clements wrote:

>
> Michael O'Dell wrote:
>
>> I hope that I am not wasting people's time with a trivial problem, but
>> I have built and installed Grass 5.0.0 on my Mac (OS X 10.1.5) and
>> installed XDarwin (see below for full list of libraries). But when I
>> issue the command 'grass5' I get the following message
>>
>> % grass5
>> % /usr/local/grass5/etc/Init.sh: no such file or directory:
>> /usr/local/grass5/etc/lock [50]
>
> This is the problem; the file error.log should indicate that an error
> occurred while building src/general/init. Examine the output from
> "make" to determine exactly what happened.
>
>> mpodell is currently running GRASS. Concurrent use not allowed.
>> %
>
> This error message is misleading. What actually happened is that the
> "lock" program failed. Normally that would indicate an existing
> session, but in this case it is because the "lock" program doesn't
> exist.
>
> -- 
> Glynn Clements <glynn.clements at virgin.net>
>
------
Scott W. Mitchell						smitch at geog.utoronto.ca
Department of Geography					Phone: (613) 730-5375
University of Toronto at Mississauga	UTM fax: (905) 828-5273
3359 Mississauga Road					Local fax (613) 822-5143
Mississauga, ON L5L 1C6					Canada