[GRASS5] Pre4 on Mac OS X

[Jeshua Lacock]

On Tuesday, May 28, 2002, at 02:54 PM, Glynn Clements wrote:

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

Yes I apologize, I realized that after sending the message.

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

Thank you very much for the explanation.

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

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

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

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

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

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

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


Thanks,

Jeshua Lacock __________________________
Programmer/Owner            Phone:   760.935.4736
http://OpenOSX.com           Fax:        760.935.4845
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_