[GRASS5] Pre4 on Mac OS X

[Glynn Clements]

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.

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

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

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

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

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