[GRASS5] PNG driver: libgd2 pickup problem

[Markus Neteler]

On Tue, Apr 23, 2002 at 01:01:06PM +0100, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > > > This indicates, that libgd1.8 is used, but the driver compiled against
> > > > 2.x. Any suggestions to solve this run-time problem?
> > > > 
> > > > ldd /mpa_sw/ssi/BIO/software/GRASS5.0.0/grass5bin_cvs/grass5/driver/PNG
> > > >         libgd.so => /usr/lib/libgd.so (0x40017000)
> > > >         libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4004a000)
> > > >         libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40080000)
> > > >         libpng.so.2 => /usr/lib/libpng.so.2 (0x4009f000)
> > > >         libm.so.6 => /lib/libm.so.6 (0x400d6000)
> > > >         libc.so.6 => /lib/libc.so.6 (0x400f8000)
> > > >         libttf.so.2 => /usr/lib/libttf.so.2 (0x4022d000)
> > > >         libz.so.1 => /usr/lib/libz.so.1 (0x40257000)
> > > >         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> > > 
> > > 
> > > Make sure the libpng library comes first when loading,
> > > e.g. in LD_LIBRARY_PATH.
> > > Ldd has to show the right one. Check the path,
> > > e.g. following through on:
> > > 	ls -l /usr/lib/libpng.so.2
> > 
> > How easy... Thanks:
> > 
> > export LD_LIBRARY_PATH=/usr/local/lib:/usr/lib:/software/GRASS5.0.0/lib
> > 
> > d.mon PNG
> > PNG: GRASS_TRUECOLOR status: TRUE
> > PNG: collecting to file: map.png,
> >      GRASS_WIDTH=640, GRASS_HEIGHT=480
> > Graphics driver [PNG] started
> > 
> > 
> > Bingo. Obviously I was confused by this comment:
> > http://grass.itc.it/pipermail/grass5/2002-March/002225.html
> >  "Note: LD_LIBRARY_PATH won't affect which version is used; the two
> >  libraries will have different sonames (libgd.so.1 vs libgd.so.2)."
> 
> I had forgotten that I had to add the soname explicitly. Normally, the
> soname will include the major version (in the above "ldd" output, this
> is true for everything except libgd).
> 
> > According to config.log the correct libgd (2.x) is used after several tries,
> > But above statement seems not to be true, since your (Bernhard's) suggestion
> > works.
> 
> Note that you only get the unversioned link (e.g. "libgd.so") if you
> install the appropriate "-devel" package (e.g. "gd-devel"). The "user"
> package (e.g. "gd") only includes a versioned link (e.g. "libgd.so.1").
> 
> The unversioned links are for compilation; if you give the linker a
> switch such as "-lgd", it will search for "libgd.so" then "libgd.a". 
> If the resulting shared library has an embedded soname, that is what
> is embedded into the executable, shown by "ldd", and used by the
> loader to locate the library.
> 
> > It is still a slightly unpleasant solution, since other programs started
> > inside GRASS session may fail now (not sure, perhaps 2.x is fully downward
> > compliant).
> > 
> > Anyway, for now I get my truecolor PNG.
> 
> I would still recommend re-linking libgd with an explicit soname.

Well, I am no root here unfortunately (or fortunately?).

This solution works:

gcc -L/hardmnt/thuille1/ssi/cvsgrass_exp/src/libes/LIB.i686-pc-linux-gnu
-o\ /ssi0/ssi/neteler/cvsgrass_exp/dist.i686-pc-linux-gnu/driver/PNG\
OBJ.i686-pc-linux-gnu/Can_do.o OBJ.i686-pc-linux-gnu/Clr_table.o\
OBJ.i686-pc-linux-gnu/Color.o OBJ.i686-pc-linux-gnu/Draw_line.o\
OBJ.i686-pc-linux-gnu/Get_w_box.o OBJ.i686-pc-linux-gnu/Get_w_line.o\
OBJ.i686-pc-linux-gnu/Get_w_pnt.o OBJ.i686-pc-linux-gnu/Graph_Clse.o\
OBJ.i686-pc-linux-gnu/Graph_Set.o OBJ.i686-pc-linux-gnu/Panel.o\
OBJ.i686-pc-linux-gnu/Polygn_abs.o -ldriver -lgis\
/usr/local/lib/libgd.so.2.0.0 -lfreetype   -ljpeg   -lpng  -lz  -lm\

ldd /ssi0/ssi/neteler/cvsgrass_exp/dist.i686-pc-linux-gnu/driver/PNG
        /usr/local/lib/libgd.so.2.0.0 => /usr/local/lib/libgd.so.2.0.0 (0x40017000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40050000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40086000)
        libpng.so.2 => /usr/lib/libpng.so.2 (0x400a5000)
        libz.so.1 => /usr/lib/libz.so.1 (0x400c6000)
        libm.so.6 => /lib/libm.so.6 (0x400ea000)
        libc.so.6 => /lib/libc.so.6 (0x4010c000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Looks dirty but working. So if "configure" would only do that for the
truecolor support, the workaround is done (if that's possible to do in
configure).

Markus