[GRASS5] PNG driver in binary release

[Glynn Clements]

mlennert at club.worldonline.be wrote:

> - it is linked to libgd.so.1.8. I have libgd.so.1.8.4, so I had to
> create a symbolic link to that file. Wouldn't it be easier to link to
> libgd.so.1 which will normally be linked to the latest version of
> libgd1 ?

The link is performed using "-lgd". This will link against either
libgd.so or libgd.a. The actual name which is stored in the executable
is the "soname" from the shared library itself. This is determined
when the shared library is built.

Normally, the soname which the developer chooses reflects the
stability of the interface. If they use the minor version component
(e.g. "libgd.so.1.8" rather than just "libgd.so.1"), that implies that
a change in the minor version will break compatibility.

[The C++ library provides an extreme example; it is typically called
something like libstdc++-libc6.1-1.so.2; this indicates that it was
built for libc6.1-1, and that any programs which use the C++ library
will only work with the exact same version of libc.]

However, the GD developers don't seem to have a particularly good
understanding of these issues, so the inclusion of the minor version
may be purely arbitrary.

OTOH, the soname may have been added by the OS distribution vendor
(e.g. if they have been burned by incompatibilities in the past).

> - because it is linked to libgd1, truecolor support doesn't work ? 
> Would it be possible to build the binary release against libgd2, or
> would that exclude to many users (those that don't have libgd2) ?

GD 2.x is currently deemed "beta", so that probably shouldn't be the
default. It might be worth providing a GD-2 version of the PNG driver
separately, or even including it in the distribution in addition to
the GD-1 version.

A similar argument applies to supplying a PostgreSQL-enabled version
of NVIZ.

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