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