[GRASSLIST:2858] Re: Compilation problem w/5pre2: flate.c (zlib?)

[Glynn Clements]

nsmith at holycross.edu wrote:

> I'm failing to complie GRASS5pre2 on YellowDogLinux.    At 
> src/libes/gis, here's what happens:
> 
> gcc -g -O2  -I/usr/include/pgsql/ -I/usr/include 
> -I/home/nsmith/grass5.0.0pre2/src/include  -I/usr/incl
> ude  -c flate.c -o OBJ.powerpc-unknown-linux-gnu/flate.o
> flate.c: In function `break_compile':
> flate.c:123: `NULL' undeclared (first use in this function)
> flate.c:123: (Each undeclared identifier is reported only once
> flate.c:123: for each function it appears in.)
> make[1]: *** [OBJ.powerpc-unknown-linux-gnu/flate.o] Error 1
> make[1]: Leaving directory `/home/nsmith/grass5.0.0pre2/src/libes/gis'
> GISGEN failure at STEP: src/libes/gis
> 
> Earlier postings seem to describe a similar problem as a failure to find 
> zlibs.  I have configured (somewhat redundantly) using
>   ./configure --with-includes="/usr/include/pgsql/ /usr/include"  
> --with-zlib-includes=/usr/include  --with-libs=/usr/lib --with-zlib-
> libs=/usr/lib
> 
> and seem to get reasonable output:  in src/CMD/head/head.ARCH I have the 
> following values (correct for my system):
> ZLIB                = -I/usr/include  -L/usr/lib -lz
> ZLIBINCPATH         = -I/usr/include
> ZLIBLIBPATH         =  -L/usr/lib

These are not correct. You should (almost) never specify
"-I/usr/include". /usr/include will searched regardless of any -I
switches; specifying "-I/usr/include" just causes it to be searched
too early.

> So if it's not a failure to find zlib, is it another library problem, or 
> something else I'm missing?

It's quite possibly related to the fact that one of the PostgreSQL
headers is called "config.h". Try configuring without using
/usr/include for any of the --with-includes or --with-[whatever]-includes
switches.

If that doesn't work, you'll need to use a more recent version of
GRASS (e.g. a CVS snapshot). GRASS' own src/include directory should
take precedence over all system include directories in recent
versions.

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