[GRASS5] Pre4 on Mac OS X

[Glynn Clements]

Jeshua Lacock wrote:

> > > To successfully build "src/libes/proj", I had to edit geod.c: It was
> > > pciky about the order of including "ctype.h".
> >
> > What exactly was the problem? Error messages?
> >
> > If a header fails to compile after ctype.h has been included, we may
> > need to change the header.
> 
> Here it is:
> 
> gcc -I/usr/src/grass5.0.0pre4/src/include -O2 -no-cpp-precomp 
> -D__unix__   -I.   -c geod.c -o OBJ.powerpc-apple-darwin5.4/geod.o
> In file included from geod.c:9:
> /usr/include/ctype.h:128: parse error before `.'
> /usr/include/ctype.h: In function `__istype':
> /usr/include/ctype.h:130: `c' undeclared (first use in this function)
> /usr/include/ctype.h:130: (Each undeclared identifier is reported only 
> once
> /usr/include/ctype.h:130: for each function it appears in.)
> /usr/include/ctype.h: At top level:
> /usr/include/ctype.h:135: parse error before `.'
> /usr/include/ctype.h: In function `__isctype':
> /usr/include/ctype.h:137: `c' undeclared (first use in this function)

1. Your original patch was reversed. ctype.h currently comes after
geodesic.h and emess.h, and needs to come before.

2. geodesic.h should *definitely* be included last.

The problem is that geodesic.h contains (amongst other things):

	# define a	GEODESIC.A
	...
	# define S	GEODESIC.DIST
	# define f	GEODESIC.FLAT

This is absolutely asking for problems if any headers are included
after geodesic.h.

CC'd to Frank, because this will apply equally to the standalone PROJ
distribution.

> geod.c: In function `main':
> geod.c:133: warning: return type of `main' is not `int'
> make: *** [OBJ.powerpc-apple-darwin5.4/geod.o] Error 1
> 
> I have actually ran into this quite a few times building various 
> pacakges, and it is just a matter of the order of the includes, or not 
> the right ones included.

In general, headers should be included in the order:

1. Core system headers (stdio.h, ctype.h, ...)
2. Headers for non-core system components (X11, libraries).
3. Headers for core systems of the package being compiled (gis.h, ...)
4. Headers for the specific library/program being compiled (geodesic.h, ...)

Each class of header has an obligation to be compatible with those
above it in the list, but not those below it.

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

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

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.

> Also, when I quit Grass, I select the "close all X windows" option, and 
> all the windows and menus close, except for the actual monitors.

Alex reported the cause of this a couple of days ago:

	Subject: [GRASS5] winname.h inconsistency found
	Date: Sun, 26 May 2002 17:27:43 +0400
	Message-ID: <20020526172743.A30504 at asrv.fcpf.ru>
	From: Alex Shevlakov <alex at asrv.fcpf.ru>

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

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.

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

And what are the linker errors if you don't add "-liconv"?

> And I had to:
> 
> *** orig/dbmscap.c      Tue Apr  9 02:09:48 2002
> --- new/dbmscap.c       Tue May 28 00:43:26 2002
> ***************
> *** 1,3 ****
> --- 1,4 ----
> + #include <sys/types.h>
>    #include <dirent.h>
>    #include <string.h>
>    #include <stdlib.h>

OK, I'll fix that.

Except: Radim: isn't dbmscap meant to be dead now?

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