[GRASS5] Pre4 on Mac OS X
jeshua at SierraMaps.com
Wed May 29 22:45:16 EDT 2002
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
>>>>>> 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:
>>>>> 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
>>> 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
> 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
>>>> 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
>>> 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
>> 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.])
>>> 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:
> 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
> What is the "architecture" name for Darwin (i.e. the suffix of the
> head.<arch> file and the OBJ.<arch> directories)?
Note the 5.4 is subject to change as it is the version:
hostinfo | grep 'Kernel Version'
% Darwin Kernel Version 5.4:
More information about the grass-dev