[GRASS5] Pre4 on Mac OS X

[Jeshua Lacock]

On Wednesday, May 29, 2002, at 10:00 PM, Glynn Clements wrote:

> From: Glynn Clements <glynn.clements at virgin.net>
> Date: Wed May 29, 2002  10:00:52 PM US/Pacific
> To: Jeshua Lacock <jeshua at sierramaps.com>
> Cc: GRASS5 <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] Pre4 on Mac OS X
>
>
> 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.

Cool. here it is:

% nm -x libgeo.a

/usr/src/grass5.0.0pre4/src/libes/vect32/georef/LIB.powerpc-apple-darwin5.
4/libgeo.a(vars.o):
00000050 01 00 0000 00000001 _ax
00000050 01 00 0000 00000005 _ay
00000050 01 00 0000 00000009 _bx
00000050 01 00 0000 0000000d _by
00000004 01 00 0000 00000011 _reg_cnt
00000050 01 00 0000 0000001f _residuals
00000008 01 00 0000 0000002a _rms
00000028 01 00 0000 0000001a _use

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

The 3rd one:

% grass5

GRASS 5.0.0pre4 > tcltkgrass&


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

OK, so I assue it would be best to remove the malloc includes?

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

Looks good to me.


Thanks,

Jeshua Lacock __________________________
Programmer/Owner            Phone:   760.935.4736
http://OpenOSX.com           Fax:        760.935.4845
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_