[GRASS5] PNG (was releases - some remarks)

[Glynn Clements]

Richard Greenwood wrote:

> > FWIW, the 5.3 PNG driver should work fine with 5.0.3; i.e. you should
> > be able to drop the 5.3 driver/PNG.exe into a 5.0.3 installation
> > without any complications.
> > 
> > Is the 5.0.3 PNG driver built with GD 2.x? If not, it might be worth
> > making the 5.3 version available separately for any 5.0.3 users who
> > want to create 24-bit PNGs (GD 1.x only supports 8-bit PNGs).
> 
> Yes, my 5.0.3 is compiled with GD 2.x. However I have a new PNG related 
> problem - when building 5.7 it fails in display/drivers/PNG. The full 
> output is pasted below. There are various references to xdr_ types and 
> functions. I have a current sun rpc installed.
> 
> Suggestion?

> /cygdrive/e/projects/grass/grass57_exp_2004_03_13/dist.i686-pc-cygwin/lib/libgra
> ss_gis.a(opencell.o)(.text+0x780):opencell.c: undefined reference to 
> `xdrmem_create'

Short version:

Add $(XDRLIB) anywhere after $(LIBES) in the actual link command (the
last non-empty line in display/drivers/PNG/Makefile).

Long version:

This is due to an error in the 5.7 Makefile; libgis uses XDR functions
for storing FP values, so anything which uses libgis also requires the
library which provides the XDR functions (the $(XDRLIB) variable
exists for this purpose).

On Linux, the XDR functions are in GNU libc, which is linked
automatically, so forgetting to add $(XDRLIB) to the link command
won't actually cause any problems.

On Cygwin, the XDR functions are in a separate library (librpclib.a)
so, if the Makefile omits $(XDRLIB), the link will fail.

So, add $(XDRLIB) anywhere after $(LIBES) in the actual link command
(the last non-empty line in display/drivers/PNG/Makefile).

Ultimately, include/Make/Grass.make.in should be re-written so that
the definition of GISLIB includes $(XDRLIB); it already includes some
of its dependencies, but not XDRLIB.

OTOH, this approach can result in the executables having unnecessary
dependencies when the GRASS libraries are built as static libraries. 
E.g. GISLIB has $(SOCKLIB) as a dependency, although that is only
actually required for the functions in lib/gis/unix_socks.c. 
Consequently, all programs which use libgis will have a dependency
upon $(SOCKLIB), although most of them don't actually need it.

It's arguable that $(SOCKLIB) should be moved to the libraries which
actually use the G_sock_* functions (i.e. libraster and libdriver).

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