[GRASS5] GRASS compilation on cygwin and IRIX

Andreas Lange Andreas.Lange at Rhein-Main.de
Thu Sep 6 07:22:53 EDT 2001

Hi Glynn, Hi all,

thanks Glynn for your patience and time. 

Glynn Clements wrote:
> Andreas Lange wrote:
> > Problem is on cygwin:
> > my configure line:
> > ./configure --prefix=$INST --with-postgres-root=/usr \
> > --with-postgres-includes=/usr/include/postgresql \
> > --with-postgres-libs=/usr/lib \
> > --x-includes=/usr/X11R6/include \
> > --x-libraries=/usr/X11R6/lib \
> > --with-tcltk-libs=/usr/local/lib \
> > --with-tcltk-includes=/usr/local/include \
> > --with-gd-libs=/usr/local/lib \
> > --with-gd-includes=/usr/local/include \
> > --with-png-libs=/lib \
> > --with-png-includes=/usr/local/include
> Note: don't specify any directories in which the preprocessor/linker
> will look automatically.
> I wouldn't have thought it necessary to specify anything other than:
>         --with-postgres-includes=/usr/include/postgresql \
> The X directories should be determined automatically, and the rest
> should be searched automatically.

Yes you are right, this was from the previous versions where configure
was not able to find the libaries. 

> > sinppet from config.log:
> >
> > configure:4546: checking for location of PNG includes
> > configure:4578: checking for png.h
> > configure:4588: gcc -E  -I/usr/local/include conftest.c >/dev/null
> > 2>conftest.out
> This indicates that png.h is found.
> > configure:4618: checking for location of PNG library
> > configure:4647: checking for png_read_png in -lpng
> > configure:4666: gcc -o conftest -g -O2    conftest.c -lpng -lz 1>&5
> This indicates that libpng is found (and contains png_read_png).
> > configure:4696: checking for location of GD includes
> > configure:4728: checking for gd.h
> > configure:4738: gcc -E  -I/usr/local/include conftest.c >/dev/null
> > 2>conftest.out
> This indicates that gd.h is found.
> > configure:4768: checking for location of GD library
> > configure:4797: checking for gdImageCreate in -lgd
> > configure:4816: gcc -o conftest -g -O2    conftest.c -lgd   1>&5
> This indicates that libgd is found (and contains gdImageCreate).
> > configure:4889: checking for gdImageGif
> > configure:4917: gcc -o conftest -g -O2    -lgd conftest.c  1>&5
> > /cygdrive/c/DOKUME~1/ADMINI~1/LOKALE~1/Temp/ccgn0CNd.o: In function
> > `main':
> > /home/Administrator/cygwin/extra/grass-5/tmp/grass/configure:4911:
> > undefined reference to `gdImageGif'
> [snip]
> But it doesn't contain gdImageGif ...
> > configure:4889: checking for gdImagePng
> > configure:4917: gcc -o conftest -g -O2    -lgd conftest.c  1>&5
> > /cygdrive/c/DOKUME~1/ADMINI~1/LOKALE~1/Temp/ccqOKwxV.o: In function
> > `main':
> > /home/Administrator/cygwin/extra/grass-5/tmp/grass/configure:4911:
> > undefined reference to `gdImagePng'
> [snip]
> ... or gdImagePng. So what formats does it support?
> > First, why is gdImageGif checked? GIF support was officially dropped in
> > gd some time ago.
> GRASS doesn't support GIF, but GD does. Some versions (e.g. the one
> which came with RedHat 6.2) only support GIF. As the only differences
> to PNGdriver are:
> a) whether to call the output file "map.gif" or "map.png",
> b) whether to call gdImageGif or gdImagePng in Graph_Close,
> I figured that it was worth supporting GD libraries without PNG
> support.
> gdImageGif writes "non-LZW" GIFs. The data stream is still valid to
> the LZW decompressor, but the compressor uses a degenerate encoding
> that eliminates the use of the technique which is covered by the
> UniSys patent.

Problem is that the official version of gd from boutell.com does not
support gif. But there are different patched versions out on the net
which support gif (without lzw compression) and gif (with lzw
compression). The UniSys patent is IMHO not applicable for some
countries. So some people prefer the lzw-gif version over the non-gif
png version. 

> > The gdImagePng(); test fails, even if i manually compile a test program.
> > But the test programs from gd-1.8.4 all compile. I have at the moment no
> > time to investigate further.
> >
> >
> > Now i re-run configure on Linux and the gd library is not found, too:
> >
> > configure:4783: checking for gd.h
> > configure:4793: gcc -E  -I/usr/local/include conftest.c >/dev/null
> > 2>conftest.out
> > configure:4823: checking for location of GD library
> > configure:4852: checking for gdImageCreate in -lgd
> > configure:4871: gcc -o conftest -g -O2    conftest.c -lgd   1>&5
> [snip]
> Note that GD is tested twice, once without $PNGLIB, and once with. If
> your libgd is linked against libpng (and doesn't have dependency
> information), the first test will fail. The above is the first test
> failing. It's the second test which is relevant.

On my Linux system (Red Hat 7 based) i have installed the latest gd
(1.8.4) version. This is linked against jpeg. So the second test does
fail too. 
This is the reason that libgd is _not_ found by configure. There should
be an additional test with $JPEGLIB added. 

For unknown reasons the gd lib on cygwin seems to be broken. 

This snippet: 

#include "gd.h"
#include "png.h"

int main() {
gdImagePtr im;
FILE *out;
(void) gdImagePng(im, out);

compiles on my linux box only with:
gcc -lgd -lpng -ljpeg test-gd.c

on cygwin:

$ gcc -L/usr/local/lib -lgd -lpng -ljpeg -lz test-gd.c
undefined reference to `gdImagePng'
collect2: ld returned 1 exit status

(same with re-ordering of libraries, adding -lz etc, other paths etc.)

But with the latest CVS updates there are more problems on cygwin:

$ cat error.log
GRASS GIS compilation log
Start of compilation: Thu Sep  6 09:38:18  2001
Compilation error in module: src/imagery/i.fft (ignored)
Compilation error in module: src/imagery/i.zc (ignored)
Compilation error in module: src/raster/r.surf.fractal (ignored)
Compilation error in module: src.contrib/GMSL/NVIZ2.2 (ignored)
Compilation error in module: src.contrib/CERL/imagery/i.shape (ignored)
End of compilation:   Thu Sep  6 10:20:46  2001
DONE generating GRASS GIS binary code

except for NVIZ this is new. 
And src.garden/grass.postgresql does not build any longer too.
There is a hardcoded -lipc somewhere, this is -lcygipc on cygwin. 

I have currently not the time to investigate all this further.

I want to ask for some more time, so that i can look. The problem is
that all the recent changes (which are really welcome by me) have to be
tested on different platforms (cygwin, BSD-systems). 

Please let us not drop the platform-independence of GRASS just to get
the final version out this week. I invested a lot of time in the cygwin
setup, so that i have to insist on fixing the problems first.

until later,


More information about the grass-dev mailing list