[GRASS5] Pre4 on Mac OS X

[Glynn Clements]

Jeshua Lacock wrote:

> >>>> Linking in "vars.o" fixed the problem. I realize it is abit of a hack
> >>>> but it seems to work:
> >>>
> >>> But vars.o *should* be in libgeo.a. Does it appear in the output of
> >>> "ar t libgeo.a"? Did you build from a clean tree, or was an older
> >>> version of libgeo.a present?
> >>
> >> Yes, it is in libgeo.a. I think it may be a linker bug with Darwin or
> >> something as much as I can guess.
> >>
> >> Yes, it was built from a clean tree.
> >
> > Then I would have to suspect a linker bug, or at least some odd
> > linking semantics which the build mechanism doesn't currently handle.
> 
> You you think my hack is acceptable? What would be the best thing to 
> test to make sure it works?

I'd rather try to find out why it fails to link against the vars.o
which is in libgeo.a. Can you send me the appropriate part of the
output from "nm libgeo.a" (the part that refers to vars.o)?

Another odd thing is that there are two other symbols in vars.o,
"residuals" (an array) and "reg_cnt" (an int), but these don't appear
in your error message.

> > No. The environment variable GISRC should be set (to $HOME/.grassrc5)
> > at startup. Scripts should call g.gisenv to read settings from that
> > file. C programs use G_getenv().
> 
> OK, so it is.
> 
> And when I do a 'g.gisenv get=GISDBASE', I get the valid path, so I 
> wonder why I have to set the variable by hand. I am trying to figure it 
> out...

Is this from starting GRASS with the tcltk option (e.g. "grass5 -tcltk",
or just "grass5" if ~/.grassrc5 has "GRASS_GUI: tcltk"), or starting
GRASS with the text interface then running "tcltkgrass" separately?

> >> Looking at r.sun:main.c, it includes both stdlib.h and malloc.h. So
> >> should I remove malloc?
> >
> > Remove the "#include <malloc.h>", and tell me if you get any errors as
> > a result.
> 
> For r.sun:main.c I did not get a error by removing malloc.h.

I suspect that the use of malloc.h is just a "DOS programmer" artifact.

> >>> And what are the linker errors if you don't add "-liconv"?
> >>
> >> I get:
> >>
> >> /usr/bin/ld: Undefined symbols:
> >>
> >> _libiconv
> >> _libiconv_close
> >> _libiconv_open
> >
> > WTF???
> >
> > So, the test program which "configure" generates links fine, but the
> > actual program doesn't. I don't see how I can make this test work for
> > Darwin without making it fail for everything else.
> >
> > Well, there is the obvious "special case" approach:
> >
> > 	if [ "$ARCH" = "...darwin..." ] ; then
> > 		ICONVLIB=-liconv
> > 	fi
> >
> > What is the "architecture" name for Darwin (i.e. the suffix of the
> > head.<arch> file and the OBJ.<arch> directories)?
> 
> powerpc-apple-darwin5.4

OK, I'll catch this with something like:

	case "$ARCH" in
	powerpc-apple-darwin*)
		ICONVLIB=-liconv ;;
	esac

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