[GRASS5] Pre4 on Mac OS X

[Jeshua Lacock]

On Wednesday, May 29, 2002, at 03:32 PM, Glynn Clements wrote:

>
> Jeshua Lacock wrote:
>
>>> 2. geodesic.h should *definitely* be included last.
>>
>> OK, I just moved string.h to above geodesic.h:
>>
>>    # include "projects.h"
>>    # include <ctype.h>
>>    # include <stdio.h>
>>    # include <string.h>
>>    # include "geodesic.h"
>>    # include "emess.h"
>>
>> And it builds without a problem. Do you think that is better?
>
> The fix which I've commited has:
>
> 	# include <stdio.h>
> 	# include <ctype.h>
> 	# include <string.h>
> 	# include "projects.h"
> 	# include "emess.h"
> 	# include "geodesic.h"
>
> This ordering (ANSI headers first, then the other local headers, with
> geodesic.h last) should be the least likely to break if anything is
> changed in the future.

Coolio, that does trick here.

>>>>>> I have run into some linking trouble with geo.point:
>>>>>>
>>>>>> gcc -L/usr/src/grass5.0.0pre4/src/libes/LIB.powerpc-apple-
>>>>>> darwin5.4   -o
>>>>>> /usr/src/grass5.0.0pre4/dist.powerpc-apple-darwin5.4/etc/geo.point
>>>>>> OBJ.powerpc-apple-darwin5.4/bin_point.o  LIB.powerpc-apple-
>>>>>> darwin5.4/libgeo.a -lgis -llock  -I/usr   -lz
>>>>>> /usr/bin/ld: Undefined symbols:
>>>>>> _ax
>>>>>> _ay
>>>>>> _bx
>>>>>> _by
>>>>>> _use
>>>>>
>>>>> These are defined in src/libes/vect32/georef/vars.c, which should be
>>>>> part of libgeo. Were there any errors in building libgeo?
>>>>
>>>> Negative, there was no error building libgeo.
>>>>
>>>> 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?

>>>> However, it did complain that I did not set the GISDBASE environment,
>>>> which I have not needed to set it before. Once I set it everything
>>>> seems
>>>> ok.
>>>
>>> What complained?
>>
>> d.rast, d.profile, d.vect.area, etc. Any button that lists the DBs
>> vector, raster or site data will display the error, unless I manually
>> set GISDBASE, as far as I tested.
>
> Well, the "tcltkgrass" script should have:
>
> 	set env(GISDBASE) [exec g.gisenv get=GISDBASE]
> 	set env(LOCATION_NAME) [exec g.gisenv get=LOCATION_NAME]
> 	set env(MAPSET) [exec g.gisenv get=MAPSET]
>
>>> GISDBASE isn't meant to be an "environment variable", it's a setting
>>> in $GISRC. Although most of the GRASS documentation is totally
>>> confused on this issue, as was some of the code (mostly, code written
>>> in Bourne shell, Tcl or perl; code written in C used G_getenv(), which
>>> got it right).
>>>
>>> The startup used to reflect the contents of $GISRC into the
>>> environment; it doesn't any more.
>>
>> Hmm, so do I need to source $GISRC or something whenever the database 
>> is
>> set/changed?
>
> 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...

>>>> Note that I also had to change "<malloc.h>" to  "<sys/malloc.h>" for
>>>> main.c in r.sun and for main.c, dataoct.c, oct.c, user2.c, user4.c in
>>>> s.vol.rst.
>>>
>>> What functions are those files using? I.e., what functions does the
>>> compiler complain about if you don't include malloc.h?
>>
>> Hmm, it just reports about not being able to find malloc:
>>
>> main.c:46: malloc.h: No Such File or directory.
>
> No, I mean if you remove the #include statement from main.c.
>
>>> For malloc(), the correct header to include is stdlib.h, although
>>> certain DOS compiler vendors seemed to think that it belonged in
>>> malloc.h, and a great many DOS programmers seem to have believed the
>>> vendors.
>>
>> 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 had to add "-liconv" in src/display/d.text.freetype.
>>>
>>> Odd. The configure script should already handle this:
>>>
>>> 	AC_CHECK_FUNC(iconv, ICONVLIB=, [
>>> 	AC_CHECK_LIB(iconv, iconv, ICONVLIB=-liconv, [
>>> 	AC_CHECK_LIB(giconv, iconv, ICONVLIB=-lgiconv, [
>>> 	    AC_MSG_WARN([*** Unable to locate iconv() function.])
>>> 	    ICONVLIB=
>>> 	])])])
>>> 	AC_SUBST(ICONVLIB)
>>>
>>> What is the definition of ICONVLIB in your head.<arch> file?
>>
>> Ah, it is empty.
>>
>>> 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

Note the 5.4 is subject to change as it is the version:

    hostinfo | grep 'Kernel Version'

%         Darwin Kernel Version 5.4: