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
/cygdrive/c/DOKUME~1/ADMINI~1/LOKALE~1/Temp/ccIa0X86.o(.text+0x17):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
Errors:
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,
Andreas