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@asrv.fcpf.ru>
From: Alex Shevlakov <alex@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@virgin.net>