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

[Glynn Clements]

Scott W Mitchell wrote:

> 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.

The key is to save the output from "make", and to post the exact error
messages. The error.log file only indicates what failed, not why.

> 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,

Is this based upon error messages which you are getting, or just from
previous postings? In -pre5, src/general/init failed on some systems
because of a problem with E_edit_cellhd, but that should be fixed in
the final 5.0.0 release.

The only program from src/general/init which calls E_edit_cellhd() is
etc/set_data (this is the one which displays the form for selecting
the database directory, location and mapset). It is also the only one
which uses the curses library, so that might be an issue.

As etc/set_data is the first program which is built from this
directory, if that fails, nothing from src/general/init will be built. 
These programs are part of the startup sequence, so if they aren't
built, GRASS won't start, and it won't really matter whether the rest
of GRASS works.

> and
> following the thread back further it seems that libgeo.a never
> successfully compiled (also missing symbols, _ax, _ay, ...).

OK; that is a known problem with MacOS X, which requires manual
intervention AFAIK (it seems to be due to a peculiarity with the Mac's
linker, but I haven't discovered any more than that). However, it
should only affect a few programs related to digitising; GRASS should
still start successfully, and the rest of GRASS should work.

> 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 ?

Not really; it will work, but it's inefficient.

> 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 ?

The difference is that running "make > build.log" then reading
build.log is likely to require less effort than manually running
multiple "gmake5 <directory>" commands.

-- 
Glynn Clements <glynn.clements at virgin.net>